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.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2012-07-15 Anthony Lawrence