If I have a windows client read a file on a Linux smb share at an interval <= 10 seconds, the windows client will show incorrect (cached?) information of that file.

I've reproduced this on multiple systems.

Example steps to reproduce:

1) set up linux samba share - for this example, using Debian and installing samba. example:

sudo mkdir /test
sudo chmod 777 /test

smb.conf addition:

read only = no    
locking = no    
path = /test/    
guest ok = yes

2) Map this directory as a drive in a windows client (this test will use L:)

3) create a file with some text on the samba server

nano /test/test.txt

4) create simple batch file on windows machine to view file every 5 seconds:

copy con test.bat
@echo off
type L:\test.txt
timeout 5
goto 1

5) run batch file, it should show ORIGINAL every 5 seconds.

6) on linux server, change file contents

nano /test/test.txt

7) view the running batch file on windows, it will still say "ORIGINAL" every five seconds, and not "CHANGED" as the real file has.

8) terminate the batch file and wait ~ 15 seconds, OR change timeout to something > 10 seconds, and it will update properly.

Hopefully I've explained and outlined how to test this sufficiently.

Can anyone reproduce this behavior and/or suggest how to fix this?





Linux Client > Linux SMB Host shows the proper file content.

Windows Client > Windows SMB Host shows the proper file content.

It's specifically Windows Client > Linux SMB Host that does not show the proper file content at a refresh interval of <= 10 seconds.

All Windows flavors I've tested with (Win7, Win10, Server2016) exhibit the same behavior.

I have also tested different protocols on my samba share 'NT1, SMB2, SMB3', and they do not change the behavior.

NOTE: I believe this is most likely a Windows issue, but I have not received any responses on either technet or superuser in a week. This should be fairly easy to test, can anyone confirm this behavior or state otherwise?

  • Hi! Maybe is the windows client caching the file. Have you tried to setup a windows file server to see if it behaves the same. I know you need windows, but am just joking. Best solution ever: uninstall windows.
    – ncomputers
    Commented Feb 23, 2018 at 21:38
  • I have tested this on Server 2016 with the File Server role installed. The same behavior occurs. Commented Feb 23, 2018 at 22:53
  • Ok maybe next step would be to test disabling caching on server side and on client side ...
    – ncomputers
    Commented Feb 24, 2018 at 0:18

2 Answers 2


The default values for the relevant settings are:

  • oplocks = yes
  • kernel oplocks = no

(See Samba smb.conf documentation)

You can disable oplocks, as per another answer.

Alternatively, if you are running a Linux O/S with a modern kernel (2.4 or newer), you can leave oplocks = yes and instead add a line to smb.conf to enable kernel oplocks. As per kernel oplocks (S) section in documentation:

Kernel oplocks support allows Samba oplocks to be broken whenever a local UNIX process or NFS operation accesses a file that smbd(8) has oplocked. This allows complete data consistency between SMB/CIFS, NFS and local file access

When oplocks and kernel oplocks are both enabled, you should get good performance (from caching) and cache invalidation when the files are updated.

To enable kernel oplocks, add this line to your Samba configuration file:

kernel oplocks = yes
  • 1
    In the first part of your answer you emphasise that oplocks should be disabled. In the second part the quotation says enable them along with kernel oplocks. Would it be right to suggest your final example should have not only kernel oplocks = yes but also oplocks = yes? Commented Feb 10, 2019 at 10:07
  • @roaima, the default configuration is: oplocks = yes and kernel oplocks = no. So there is no need to add oplocks = yes; we just need to specify the kernel oplocks value.
    – Serge
    Commented Feb 10, 2019 at 13:40
  • 3
    I was just thinking that maybe since the first part of your question suggests disabling it, it would be worth connecting that in your final proposal. Commented Feb 10, 2019 at 14:36

I resolved this by placing

oplocks = False

in my smb.conf under my share settings.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .