Even with "ignore system acls" set to "yes", for objects without NT ACL xattr we use the underlying filesystem permissions to construct an NT ACL. This can result in *very* unexpected permissions, eg: - a directory with the following ACL: $ ./bin/smbcacls -Uslow%pass //localhost/normal "" REVISION:1 CONTROL:SR|DP OWNER:SLOW\slow GROUP:Unix Group\root ACL:SLOW\slow:ALLOWED/0x0/FULL So only one non-inheritable(!) ACE. - creating a subdirectory: $ ./bin/smbclient -Uslow%pass //localhost/normal -c "mkdir dir1" - checking whether there's an ACL xattr: $ getfattr -m "" /Volumes/normal/dir1 getfattr: Removing leading '/' from absolute path names system.posix_acl_access system.posix_acl_default user.DOSATTRIB So there isn't an ACL xattr, because there where no inheritable ACEs on the parent folder. - reading the new subdirectories ACL: $ ./bin/smbcacls -Uslow%pass //localhost/normal "dir1" REVISION:1 CONTROL:SR|DP OWNER:SLOW\slow GROUP:Unix Group\slow ACL:SLOW\slow:ALLOWED/0x0/FULL ACL:Unix Group\slow:ALLOWED/0x0/READ ACL:Everyone:ALLOWED/0x0/READ ACL:NT Authority\SYSTEM:ALLOWED/0x0/FULL The ACES for "SLOW\slow", "Unix Group\slow" and "Everyone" are coming from the underlying filesystem. This is the problem. Have patch, need bugnumber.
Created attachment 12302 [details] Patch for 4.3 and 4.4 cherry-picked from master
Pushed to autobuild-v4-[4|3]-test.
(In reply to Karolin Seeger from comment #2) Pushed to both branches. Closing out bug report. Thanks!