Server is an OS X server, 10.7.0 (Lion) Client is Windows 7 No domain controllers. No AD. All accounts local. All Samba users setup on the command line with smbpasswd -a. smb.conf is stock sample config file, with the following changes: workgroup= ... netbios name = ... log file = ... wins support = yes max protocol = SMB2 Given the following share: [myshare] comment = My Share path = /My Path browseable = yes writeable = yes User is in group with full ACL permissions to entire directory tree under the share. User can read, write, and change files. However, user cannot delete or rename files or directories. If viewing permissions in File Properties in Windows 7, the read, change, and write attributes are checked off, but the modify attribute is not. These symptoms occur even for files which are created by the user in question, who then immediately attempts to rename or delete the file. Windows 7 reports that the user does not have permissions. I verified that the user has permissions several ways. First by connecting to the Mac via AFP with the same user. User was able to create, modify, delete, rename files. Second by dropping to the user in question at the command prompt "su username". User was able to create, modify, and delete files. Here are example ACL permissions on one such file, just created by a user, who is then unable to delete or rename said file: # ls -le New\ Text\ Document.txt -rwxr--r--+ 1 prodfull projectmanagers 0 Aug 19 20:10 New Text Document.txt 0: group:everyone inherited allow read,execute,readattr,readextattr,readsecurity 1: group:prepress inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity Note that the "prodfull" user is a member of the "prepress" group.
Further note: The built-in SMBX daemons have been disabled on the server in question.
Behavior when connection to the same SMB share via Snow Leopard (10.6.8): Despite the parent directory having full read-write access, the Mac refuses to allow any files or directories to be created at all. It believes that there is no write access to the directories on the share. ACL of example directory: drwxr-xr-x@ 10 mwdiers projectmanagers 340 Aug 19 20:10 DirectoryName/ 0: group:everyone inherited allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit 1: group:prepress inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
Confirmed that this is a problem with Samba properly recognizing ACL permissions on directories. Standard Unix file permissions, however, are recognized properly. If a logged-in user owns a directory, then he can create, delete, rename, change files inside it. If he does not, even if he has inherited ACL permissions via OS X, he cannot. The following share settings do not fix the problem: browseable = yes writeable = yes inherit acls = yes inherit permissions = yes map acl inherit = yes store dos attributes = yes map readonly = no create mask = 0777 directory mask = 0777
My guess this is due to Samba 3.6 not understanding the new ACL model in OS X Lion which is NFSv4 or Windows NT-based I believe. The basic POSIX permission mapping just doesn't work for something this complex. In order to make this work we'll need a VFS module that reads and writes these native OS X ACLs - probably based on the modules/nfs4_acls.c code we already have. Can you point me at some documentation for the API's to get/set these new ACLs ? Jeremy.
I have been looking for any documentation on ACL changes in Lion. Everything I have found says that the NFS4-style ACLs in OS X have been around since 10.4. Developer docs covering ACLs have not been updated for three years. I'll keep looking.
macOS isn't really an actively supported server platform. You might want to look at: https://opensource.apple.com/source/samba/samba-235.7/patches/vfs-module-darwin-acls for ACL support on macOS. As this is from 3.x times, you will have to make several adjustments to get this work with current releases. I close this bug as wontfix here but feel free to come up here again with a working version of the Darwin acl module if you like.