Windows smb share file permissions cache / race condition issue

Problem: windows client cannot access a file on an smb share but the permissions are correct on the server

Client: Windows 10 22H2 (OS Build 19045.2006) smb dialect 3.1.1
Server: Linux - Debian 10 - buster - smbd version 4.9.5

I had an issue that a specific file on an smb share connected via windows client was inexplicably out of sync with the server permissions and ACL's. The file could be listed but read/write permission was denied. Using cygwin to list the file permissions showed disparity between the client and the server.

The file had been written by a Linux client and the Windows client had inexplicable permissions issues. Explorer, and other programs demonstrated the permissions issues. Here is how it looked like from a cygwin prompt on the windows client:

user@node-5900x //omv.blah.local/share
$ file merge.mp4 ; touch merge.mp4
merge.mp4: regular file, no read permission
touch: cannot touch 'merge.mp4': Permission denied

Cross-checking the permissions and ACL's on the server and another Linux client - everything seemed fine. Explicitly touching, chown and chmod'ing the file didn't help to wake up the windows client to see the correct permissions. Restarting smbd on the server also didn't seem to help.

Creating more new files on the Linux client and checking them on the Windows client - everything was OK... It was this specific file that was having issues.

Not sure if its related but the command that created the file (the writing binary) on the Linux node was as follows:

ffmpeg -i merge.mkv -strict experimental -c copy merge.mp4

Impact: client unable to work with the file

You could say this was a kind of service outage for the client. This would obviously impact the productivity of the person(s) working on the client.

Solution: restart the workstation service on client

The smb connection was not listed with net use, so net use was not the right approach to delete the session/connection for the share in this case. I found a few posts suggesting that a restart of the clients workstation service would clear out sessions/credentials and could solve issues - it did. I have a feeling I've used this approach in the past - it was just too long ago to remember it.

Prior to restarting the service the smb connections list looked like this via elevated PowerShell:

PS C:\WINDOWS\system32> Get-SmbConnection

ServerName       ShareName UserName         Credential       Dialect NumOpens
----------       --------- --------         ----------       ------- --------
omv.blah.local   share     NODE-5900X\user  NODE-5900X\user  3.1.1   10

To restart the workstation service - from an elevated cmd prompt:

net stop workstation && net start workstation

💡 Its important to ensure all explorer and other programs using the share are closed, otherwise this solution might not work as advertised.

Alternative: logging off the windows user and/or restarting the windows node would likely of also resolved this issue. However those approaches are disruptive and sometimes highly undesirable because they can impact peoples workflow and productivity.