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.
*Originally published at APLawrence.com
Add to document.write(“Del.icio.us”) | DiggThis | Yahoo! My Web
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
