Whose fault is it that opening the same Samba-shared file does not give updated file?

Question

In the scenario below, the app on Windows does not get the updated version of the file, but gets the old version of the file. I have two methods to get the new version in this case: (1) restart the Samba service on the Linux, or (2) call the PowerShell command Remove-SmbMapping on the Windows.

I am not sure if I had experienced this when the SMB server was Windows, but probably not, because I do not remember. If this problem only occurs when the file server is Samba on Linux, which is the cause of the problem? A bug of Samba server? A bug of Windows? Or a problem of the SMB protocol itself?

1. Share a directory on a Linux PC using Samba (4.16.2).
2. On a Windows PC, open a file on that directory and close the file.
3. On the Linux PC, modify the file.
4. On the Windows PC, open the file again.

Answer 1

It is not a bug. It is "by design with consequences".

In broad brushstrokes: there are two modes the samba server can live: as a dedicated file server and not.

The basic idea of dedicated file server is that actual storage is slow, and most users go to the files through the smb anyway - so caching the files in server's memory is efficient. The modification of files bypassing SMB is not expected. The cache is invalidated with some time period, of course, but it is out of user's control (not sure how long and where it is configured, and is it even possible to configure).

The key to this is: "opportunistic lock". oplocks key in smb.conf.

The official documentation ( https://www.oreilly.com/openbook/samba/book/ch05_05.html ) clearly states:

Oplocks should be disabled if you are accessing the same files from both Unix applications (such as vi ) and SMB clients ...