The Samba-Bugzilla – Bug 747
Offline synchronization fails if user is not owner of file
Last modified: 2005-11-14 09:29:59 UTC
When you try and synchronize a file that you have edited offline, but are not
the owner of (an easy scenario in a shared documents direcotry), Samba will
attempt to either change ctime on the file (presumably in order to set the
modification time to match the time, in the past, that the file was modified) or
the permissions of it. Because you are neither the owner, nor root, you cannot
make these changes, and it reports Access Denied to Windows.
I think the problem boils down to these lines (from the 2.2.8a log):
[2003/11/03 09:08:51, 3] smbd/dosmode.c:unix_mode(111)
unix_mode(Test/Setting up a PSC Quickscan 6000 Plus.doc) returning
[2003/11/03 09:08:51, 2] smbd/trans2.c:call_trans2setfilepathinfo(2803)
chmod of Test/Setting up a PSC Quickscan 6000 Plus.doc failed
(Operation not permitted)
[2003/11/03 09:08:51, 3] smbd/error.c:error_packet(91)
error string = Operation not permitted
[2003/11/03 09:08:51, 3] smbd/error.c:error_packet(103)
error packet at smbd/trans2.c(2804) cmd=50 (SMBtrans2)
The log of this error on 2.2 (Debian's 2.2.3a-12.3 in this instance, but
it also occurs on 2.2.8a-0.1 from samba.org) can be found at
http://www.hs.net.nz/~crb/samba/samba-l10-logs-of-sync.tar.gz. On 2.2, it
claims Access Denied, but seems to write the file, because a subsequent
synchronization will cause Windows to suggest the network file is newer
(correct) and if you select "keep version on network" the conflict is resolved.
The 3.0.0 log is at
http://www.hs.net.nz/~crb/samba/samba-3.0-l10-logs-of-sync.tar.gz - the
trans2setpathinfo doesn't cause an error, but the same result occurs, with one
important exception - the file doesn't actually write (all subsequent sync
attempts say "Access Denied".)
There are also files called "8000007E" created; I'm not sure if there are temp
files created in the process or something similar.
Jeremy, didn't you already handle this one on the samba ml ?
I've covered this on the mailing list. The problem is Windows
trying to set an ACL on the file and it being denied. If ACLs
are set up so this can be set on the file the sync works correctly.
Thanks Jeremy - I can confirm that it solves the problem as I had it on my test
The dos filemode parameter, while well documented in smb.conf, isn't very well
documented according to Google - to the point where your message to the Samba
mailing lists comes up about #4 for a search for "dos filemode"!
The answer now has pride of place on our Wiki: http://www.wlug.org.nz/SambaNotes