Bug 8388 - Files cannot be deleted or renamed even when created by same user
Files cannot be deleted or renamed even when created by same user
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: User & Group Accounts
x64 Mac OS X
: P5 critical
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2011-08-20 01:52 UTC by Martin Diers
Modified: 2014-07-07 11:04 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Martin Diers 2011-08-20 01:52:19 UTC
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:

    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.
Comment 1 Martin Diers 2011-08-20 01:53:05 UTC
Further note:

The built-in SMBX daemons have been disabled on the server in question.
Comment 2 Martin Diers 2011-08-20 01:59:44 UTC
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
Comment 3 Martin Diers 2011-08-20 02:20:36 UTC
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
Comment 4 Jeremy Allison 2011-08-20 05:15:26 UTC
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 ?

Comment 5 Martin Diers 2011-08-20 17:39:03 UTC
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.