OMV VM - SMB sharing - takes times to refresh on Windows folder

Hamlet

New Member
May 6, 2024
9
0
1
Hello,
I have a home PC used as basic NAS/Server with Proxmox. It has 2x internal SATA, NTFS HDDs that I want to share to my Proxmox containers, VM, and also my local Windows network.

I currently set up the following :
  1. - OpenMediaVault (OMV) as a VM on Proxmox.
  2. - Passed-through the two SATA HDDs to the OMV VM ("qm set" command). The drives appear as "huge QEMU" drives inside OMV.
  3. - Enabled SMB sharing inside OMV, for both HDDs.

Now, here is my trouble :
  1. - I can perfectly see the drives in my Windows local network (in Windows Explorer, "network" section)
  2. - I can add/remove files, folders through the Windows Explorer, and it will reflect immediately on the the Proxmox (shell and OMV VM console) when I check the directories.
  3. - HOWEVER, when I add/remove files from the Proxmox (either Shell or OMV VM console, for instance "mkdir test"), it takes a long time for the Windows Explorer to reflect the changes (pressing "F5" doesn't make it faster).

It doesn't feel like a material/sluggish issue. For instance, from the Windows Explorer, I can watch/go through heavy 4k videos located on the HDDs without any lag.

The weirdest is that, if for instance, i do "mkdir test" on the Proxmox, the "test" folder doesnt appear on Windows Explorer, but if I try to create a "test" folder on Windows, it will indicate me I cannot do it because "it already exists".

So the data change "is there" but it doesn't show at the Windows Explorer.

Could you help me understand what may be the issue ?
Thank you !
 
Last edited:
Hi,

Since Windows reports that the folder "already exists," it confirms that the file system operation has already been successfully executed on the server side (OMV), but the Windows client is failing to refresh its directory listing in real-time. This is a classic symptom of stale SMB metadata cache or missing change notifications.

To further isolate the issue, you might want to try the following steps within your OMV VM:

1. Isolate Server vs. Client

Run smbstatus to ensure your Windows client is properly connected. Then, try creating a test folder directly on the OMV CLI (e.g., mkdir /path/to/share/test_folder).
If this folder doesn't appear immediately on your Windows machine, the issue is likely related to how notifications are being passed or cached.

2. Driver/Filesystem Limitations (NTFS-3G)

If you are using NTFS-3G (common when using disk passthrough with Windows-formatted drives), note that this FUSE driver often struggles with inotify and change notify events.

This prevents Samba from effectively signaling Windows that a directory has changed. Using a native Linux filesystem like EXT4 or XFS on the passthrough disk would typically resolve this refresh delay.

3. Samba Configuration Tweaks

Check your Samba configuration (/etc/samba/smb.conf) for these settings to ensure notifications are enabled:

change notify = yes
kernel change notify = yes

4. Windows Client Cache

You may also try disabling the SMB directory cache on the Windows client (setting DirectoryCacheLifetime to 0) to force fresh directory listings.

As a temporary workaround, you can also try clearing the connection by running net use * /delete on Windows and remounting the share to force a full refresh.
 
Passed-through the two SATA HDDs to the OMV VM ("qm set" command). The drives appear as "huge QEMU" drives inside OMV.
HOWEVER, when I add/remove files from the Proxmox (either Shell or OMV VM console, for instance "mkdir test"), it takes a long time for the Windows Explorer to reflect the changes (pressing "F5" doesn't make it faster).

If you use disk passthrough: [1], you should not access/use that/those disk/s from/in the PVE-host as well as any other guest at all or it will most likely lead to corruption sooner or later...

Furthermore, I would start with this:
Using a native Linux filesystem like EXT4 or XFS on the passthrough disk [...]

[1] https://pve.proxmox.com/wiki/Passthrough_Physical_Disk_to_Virtual_Machine_(VM)