On my F42 system, I have a file system named /pictures, which is exported as a Samba share. It is mounted on a Windows-10 system. When this is updated on the Linux side (mass renames, etc) the changes are not reflected in the Windows File Explorer, even after a “Refresh” command. This seems to be new (or severely worsened?) since I upgraded from F41 to F42.
Is anyone else seeing this?
Is this more likely to be a Samba problem or a Windows problem?
this can happen if you rename/change files on filesystem level and not via samba. restart samba
Restarting Samba is not a good option. But is sounds like this is a Samba problem: Samba is not monitoring the file system changes.
This is a fairly recent problem: It used to work.
The problem arises out of a workflow in photo archive processing, where I run the more visual aspects from my Windows desktop, while the HEIC and JPG files reside in the Linux file system accessed from the Windows side by Samba. My wife takes 1000+ images per month on her iPhone, and the archive in my /pictures filesystem is about 120,000 images.
The workflow goes like this (simplified and abbreviated):
icloudpd into a temporary working directoryIMG_1234.HEIC to ABC_41234.HEIC to achieve uniqueness within each camera’s sequence numbers and avoid collisions between sequence numbers from multiple cameras.2025-07-Sacramento_CAindex.cgi so that the archive can be browsed as thumbnails liked to “slide shows”All of the organizing and reformatting scripts run in Perl scripts in an ssh window, but I find Windows file manager is the nicest way to see the current state of my working directory and fixing up individual file names.
I would assume that the “refresh” function in Windows file manager is a re-read of the directory. Shouldn’t Samba refresh its cache of the directory when the client asks for a re-read?
Maybe I will try next month to drive this from the Linux desktop instead of the Windows desktop, even though I like Dolphin much less than Explorer. I especially like the way that Explorer merges folders when moving a file tree update from one area to another.
Does disabling the getwd cache prevent this? It will have negative performance impact.
Restarting samba is the quickest workaround. You could also close existing connections with smbcontrol.
Usually this can occur, if you change/manipulate inodes with mv file_a file_b. I’ve seen this on RHEL6 with samba 3.x when overwriting a file with a newer version e.g. cp -p dir_b/file dir_a/file. The inode for dir_a/file remains the same, and some windows clients would still see the old mtime.
You can prevent this by creating a new inode, mv dir_a/file dir_a/file_prev && cp -p dir_b/file dir_a/ && rm dira_file_prev.
I think this is not a problem if you perform your workflow on a mounted cifs filesystem. Mount the smb share locally on the server and use that mount point for processing the images.
Otherwise change mv filea fileb to ln filea fileb && rm filea or use reflinks if supported by the FS ( btrfs , xfs?), e.g cp -p --reflink filea fileb && rm filea
update: ln (hardlinks) will not create a new inode, only a new reference in the directory. Not sure if this will work. cp --reflink creates a new file with a new inode.
I have been advised that this is a result of Samba 3 being optimized for NAS applications rather than for Workgroup sharing. I.e. Samba assumes that it “owns” the exported filesystem, and it is not expecting other programs on the exported filesystem to make changes. Your above description fits with that.
I was told that the previous behavior (which was a much better fit for my use case) can be restored by the following addition to the [global] section of /etc/samba/smb.conf:
smb3 directory leases = no