Bug reported in Debian. I was balanced about forwarding it because the bug was experienced by our user with the 3.5.6 version of version and he has no real way to try reproducing it with 3.6 (the server being a production server). The bug appeared, according to our user after he upgraded from the 2:3.5.6~dfsg-3squeeze2 version of Debian packages to 2:3.5.6~dfsg-3squeeze4. Such updates are usually made of either security fixes...or fixes for important issues where we cherry-pick fixes. The changelog between the two versions is: samba (2:3.5.6~dfsg-3squeeze4) stable-proposed-updates; urgency=low * Document the newly introduced "map untrusted to domain" parameter and its default value that can lead to disruptive behavioral changes when upgrading from pre-3.5 versions. Closes: #623190 * Fix "tdb2.so undefined symbol: dyn_get_STATEDIR" by fixing a typo in fhs-filespath.patch. Closes: #629183, LP: #789097 -- Christian Perrier <bubulle@debian.org> Sat, 11 Jun 2011 11:05:52 +0200 samba (2:3.5.6~dfsg-3squeeze3) stable-proposed-updates; urgency=low * Cherry-picked fixes from samba 3.5.8 for some important bugs: - Upstream bug 7567: printing from Windows 7 fails with 0x000003e6. Closes: #617429 - Upstream bug 6727: printer device settings not saved for normal domain users. Closes: #611177 - Upstream bug 7777: winbind leaks gids with idmap ldap backend Closes: #613624 - Upstream bug 7880: rpcclient deldriver does not remove drivers from all architectures. -- Christian Perrier <bubulle@debian.org> Sun, 13 Mar 2011 08:07:42 +0100 The problem (our user is speaking): "Now I cannot delete any file from samba share using linux samba client, even the file that has been created by the same user and the same client just before. I don't use any extended ACLs, sticky bits or so. I don't see any problem using WindowsXP clients." After some exchanges, he sent us a full lvel 10 log where the user created a test.txt file, then attempted to delete it. I attach it to this bug report. From my understanding, the problem shows up around line 4443. Do you think something can be investigated or does it ring a bell to you? I'm sorry we can't provide a report with a more recent version of samba, but that's apparently not possible for our user...
Created attachment 7554 [details] Debug log
Here is the authentication token of the connected user: NT user token of user S-1-22-1-10249 contains 6 SIDs SID[ 0]: S-1-22-1-10249 SID[ 1]: S-1-5-21-2222734727-3523169228-4078589058-514 SID[ 2]: S-1-1-0 SID[ 3]: S-1-5-2 SID[ 4]: S-1-5-11 SID[ 5]: S-1-22-2-10014 SE_PRIV 0x0 0x0 0x0 0x0 Note the primary SID is a Samba-UNIX-style SID (i.e. no mapping from a Windows name has been done). Now look at the unlink call that fails. At line 4445 we see the file has permissions: canon_ace index 0. Type = allow SID = S-1-5-21-2222734727-3523169228-4078589058-21249 uid 10249 (zalohymail) SMB_ACL_USER_OBJ ace_flags = 0x0 perms rwx canon_ace index 1. Type = allow SID = S-1-22-2-0 gid 0 (root) SMB_ACL_GROUP_OBJ ace_flags = 0x0 perms r-x canon_ace index 2. Type = allow SID = S-1-1-0 other SMB_ACL_OTHER ace_flags = 0x0 perms r-x Note that the owning user is S-1-5-21-2222734727-3523169228-4078589058-21249, which is the same as UNIX user uid 10249 - the problem is that when this user logged in the uid 10249 isn't being mapped into SID S-1-5-21-2222734727-3523169228-4078589058-21249, but into SID S-1-22-1-10249. That's the issue. The log doesn't show the user login information, so there isn't enough information to know why the lookup isn't being done. I'd suggest retrying with a later Samba version to see if the mapping of the incoming user is being done to the correct SID.
this isn't a known problem in any recent samba version, closing.