I had some issues here because we had a duplicate groupmap entry pointing to the same Unix group, which caused that user couldn't delete files using samba which they had correct unix permission to (Directory permissions set to 0775 and user was member of the directories group). With "acl check permission = false" the problem didn't occur. "net groupmap list" returned the following: Domain Users (S-1-5-21-1620896164-3410292537-1148934433-513) -> users user (S-1-5-21-1620896164-3410292537-1148934433-1201) -> users Group users has the gid 100. When deleting a file with log level 10 I got the following log: =========================== [2009/05/11 15:46:40, 3] lib/util_seaccess.c:se_access_check(252) se_access_check: user sid is S-1-22-1-1355 se_access_check: also S-1-22-2-100 se_access_check: also S-1-1-0 se_access_check: also S-1-5-2 se_access_check: also S-1-5-11 se_access_check: also S-1-22-2-809 se_access_check: also S-1-22-2-806 se_access_check: also S-1-22-2-5555 se_access_check: ACE 0: type 0, flags = 0x00, SID = S-1-22-1-1000 mask = 1f01ff, current desired = 2 se_access_check: ACE 1: type 0, flags = 0x00, SID = S-1-5-21-1620896164-3410292537-1148934433-1201 mask = 1f01ff, current desired = 2 se_access_check: ACE 2: type 0, flags = 0x00, SID = S-1-1-0 mask = 1200a9, current desired = 2 [2009/05/11 15:46:40, 5] lib/util_seaccess.c:se_access_check(316) se_access_check: access (2) denied. [2009/05/11 15:46:40, 10] smbd/open.c:create_file_unixpath(2893) create_file_unixpath: NT_STATUS_ACCESS_DENIED =========================== The user is member of the group users (which was mapped to S-1-22-2-100). But the group of the directory was mapped to the entry from the groupmap table, causing sambe to deny access to delete the file... After removing the duplicate entry from the groupmap things works as expected: ================================================ [2009/05/12 11:14:58, 3] lib/util_seaccess.c:se_access_check(252) se_access_check: user sid is S-1-22-1-1355 se_access_check: also S-1-5-21-1620896164-3410292537-1148934433-513 se_access_check: also S-1-1-0 se_access_check: also S-1-5-2 se_access_check: also S-1-5-11 se_access_check: also S-1-22-2-809 se_access_check: also S-1-22-2-806 se_access_check: also S-1-22-2-5555 se_access_check: also S-1-22-2-100 se_access_check: ACE 0: type 0, flags = 0x00, SID = S-1-22-1-0 mask = 1f01ff, current desired = 2 se_access_check: ACE 1: type 0, flags = 0x00, SID = S-1-5-21-1620896164-3410292537-1148934433-513 mask = 1f01ff, current desired = 2 [2009/05/12 11:14:58, 5] lib/util_seaccess.c:se_access_check(310) se_access_check: access (2) granted. ================================================ Now the group gets mapped to S-1-22-2-100 and the group from the groupmap, which matches the group of the ACE. Since I wasn't able to re-add the duplicate entry to the groupmap I think the Samba database was somewhat corrupted here!?! Maybe Samba or testparm should write some descriptive warnings to the logs when such an situation is detected. The Samba-Server is a member of a Win2000 Domain but winbind isn't used. The setup has received several setups in the past (started from samba 2.x.x), which may be the reason for some corrupt entries in the database...
Michael, afaik you're working on a tool that checks the validity of the idmapping database. This should print out problems like this, right? Assigning to you, you might want to update this bug when that tool is done. Thanks, Volker