Dmitry Butskoy <firstname.lastname@example.org> reports:
I've discovered an issue since the Samba 3.4, when "dos filemode =
yes" and a "not-owner with write access" tries to change file
attributes. A stale lock appear (it may vary depending on a particular
user case, the simplified test see below).
Comparing the function "smbd/open.c:open_file_fchmod()" between the
versions 3.2.15 and 3.4.8, the call of "open_file" was changed to
"SMB_VFS_CREATE_FILE()", but the correspond
"smbd/open.c:close_file_fchmod()" seems not changed in this way. I
guess this change causes the issue -- a stale WRONLY lock have
Simplified test case (using smbclient):
Samba-3.4 (3.5 is affected as well), "dos filemode = yes"
Consider a directory:
drwxrwxr-x 2 root group 4096 Dec 27 21:12 directory
two files in it:
-rw-rw-r-- 1 user group 8358 Dec 27 20:50 test0
-rw-rw-r-- 1 root group 8358 Dec 27 20:40 test1
and a user "user", who is a member of a group "group".
In other words, user owns "test0" and has write access (by group
perms) to the "test1". According to the "dos filemode = yes" the user
should be capable to change access bits for both files (not "test0"
smbclient //SERVER/SHARE -U user%password
and try to use "setmode testX +r".
After the "setmode test0 +r" the correspond bits are changed,
"smbstatus" at the "SERVER" shows no lock. (You can revert by "setmode
test0 -r" and so on as the owner of the file).
After the "setmode test1 +r", the correspond bits are changed as well,
because the "user" has write acess to this file and "dos filemode =
yes" is set. BUT after this operation, the smbstatus on the SERVER
shows a stale lock:
<pid> <uid> DENY_NONE 0x82 WRONLY NONE
/server/share directory/test1 Tue Dec 28 18:02:12 2010
Certainly, in this simplified test the stale lock disappears after you
exit the smbclient utility. But anyway it shows that something going
wrong. The initial case in my production environment (samba servers
and windows clients) is slightly different -- it seems that the
windows machine first lock for "change attributes", then another lock
for "write" (by open_file_fchmod), then the user cannot reopen the
file until reboot or relogin to the server.
Additional followup from Dmitry Butskoy <email@example.com>
Well, the correspond git change is:
When I revert it (for samba 3.4.9) the problem disappears (no any
Created attachment 6175 [details]
git-am patch for 3.5.next
Created attachment 6176 [details]
git-am patch for 3.4.next
Comment on attachment 6176 [details]
git-am patch for 3.4.next
Haven't tested it, but it looks right.
The patch fixes the issue for me (samba-3.4.9), both the simplified test and the actual case in production environment are OK now.
Bug #7631 looks like the same issue.
*** Bug 7631 has been marked as a duplicate of this bug. ***
Pushed to v3-5-test and v3-4-test.
Will be included in the next releases.
Closing out bug report.