SMB Caching

A customer had a particular shared folder setup so that only he had access to it. This happened to be a SCO Visionfs system, but you could run into similar problems with Samba.

A change in business practice required giving two other people read/write access to files in that directory. The customer had forgotten that it had originally been restricted to only his user name, so he set up mapped drives on the other two users machines and of course couldn't write to the necessary files. I was on site for other reasons, so he called me over to observe the problem.

I immediately reminded him that he probably set restrictions and we went into the Visionfs profedit tool to add the two new users and set the file creation mask appropriately. I also chmodded the files on the server so that the group of these three users could write to the files.

We restarted the Visionfs server, and tried overwriting a file. That still failed from the new users machines.

I realized it had to be caching on the users machines, so disconnected the mapped drive, reconnected, and tried again. It still failed.

That surprised me. I expected that unmapping and remapping would clear the cache, but apparently it does not. On a whim, I tried deleting a file, and that was successful. Once that had been done, any of the users could now write and overwrite as desired.

I suppose that if I had rebooted the Windows machines that would have cleared up the problem also. Windows side SMB caching can be confusing. There are various Samba notes you can find with Google; for example How *exactly* does the file caching mechanism work?. This is related to opportunistic locking, so that's another Google search that can show you more about it. See Chapter 16. File and Record Locking Part III. Advanced Configuration in the Samba docs.

Got something to add? Send me email.

1 comment

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Tue May 23 14:00:40 2006: 2044   BigDUmbDinosaur

Windows side SMB caching can be confusing.

It can also be unreliable. I always disable client side caching (csc policy = disable) in Samba -- it has saved me more than a few headaches over the years. The fact of the matter is that caching and oplocks are together more responsible for weird Windows network behavior than almost anything else. In some cases, random corruption of files can be blamed on these two "features." They do little to enhance performance on most systems, so I say turn 'em off!

Kerio Samepage

Have you tried Searching this site?

Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us