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:
netbios name = ...
log file = ...
wins support = yes
max protocol = SMB2
Given the following share:
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.
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 ?
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:
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.