After updating from 3.0.11 to 3.0.12 the ACL feature is not working properly Symptom: drwxrwx---+ root root (acl "rwx" for user mueller) When using acls on Win2k the following happens: - create file, ok - rename file, not ok - permission denied, file in use - delete file, not ok - permission denied, file in use - create directory, ok - rename directory, ok - delete directory, ok It seems that samba does not properly recognize the acl on the directory entry. Under SuSE 8.2 (shell mode) the acl support from the file system works fine. This syptom appeared just after updating from 3.0.11 to 3.0.12. The config files, *.tbf files and the partition with the ACL filesystem (reiserfs) were unchanged. Workaround: Rollback to samba3-3.0.11 and samba3-client-3.0.11, then everything was fine again.
I have the same problem in the same conditions. I use Linux Mandrake with ext2fs+Linux 2.6.10 ACL. getfacl shows that the user has rwx rights on the file but I can't delete it through a Samba share. I cant modify the content of the file. If I am logged under that user on the server I can delete the file with BASH. So the problem is not related with ACL unsufficient rights. Everything worked fine with Samba 3.0.11 and of course I hadn't changed ACL rights or smb.conf.
3 reports of this. Looks like a show stopper for 3.0.13.
The current samba ml thread: http://lists.samba.org/archive/samba/2005-March/102491.html So we have resierfs, ext2 & ext3 (all HAVE_POSIX_ACLS).
Per the request of Gerald, I can confirm that this seems indeed the same bug as mentioned on the list by me. EXCEPT: Users cannot create new files, but existing files can be saved to.
skeptix@web.de, please post the output from getfacl on the parent directory and on the file in question. Thanks. btw....I have not been able repdroduce this as of yet.
I was able to reproduce a failure using these instructions from bdbruin@aub.nl: ================ As far as I can deduct now (I am not in a position to test it now as I needed to downgrade quickly in production - I dont have the luxury of a test environment yet :-( ). You could test if the following works/does not work: - Create a directory within a share, which has normal unix permissions of 755. - Add acl's which allow additional groups to write to this directory Now as user which is different than the owner of the directory but is a member of one of the acl-added groups try to create a file in that dir. If the bug occurs than you should not be able to do this. ================
Created attachment 1099 [details] gzipped logfile of rename failure (lookup for NT_STATUS_ACCESS_DENIED) $ getfacl acl-bug # file: acl-bug # owner: root # group: root user::rwx group::r-x group:ntadmin:rwx mask::rwx other::r-x getfacl acl-bug/New\ Text\ Document.txt # file: acl-bug/New\040Text\040Document.txt # owner: jerry # group: users user::rwx group::rw- group:ntadmin:rwx mask::rwx other::r-- $ id uid=780(jerry) gid=100(users) groups=14(uucp),16(dialout),17(audio),33(video),71(ntadmin),100(users)
Created attachment 1100 [details] check for SMB_ACL_GROUP (not mask)
i've attached Jeremy's patch to posix_acls.c Fixes my test cases. Please test and let me know something soon. I think we are ready for 3.0.13 now.
(In reply to comment #5) Output of getfacl on the directory and the file, here it is: acl on the directory: # file: tm # owner: root # group: root user::rwx group::r-x group:lt-dv:rwx group:ma-dv:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:lt-dv:rwx default:group:ma-dv:rwx default:mask::rwx default:other::--- I used the setgid-bit on this directory. The unix-rights look like: drwxrws---+ 5 root root 520 Mar 24 09:23 tm With 3.0.11 I have no problems with this construction. acl on the new file: # file: newfile.txt # owner: michel # group: root user::rwx group::rw- group:lt-dv:rwx group:ma-dv:rwx mask::rwx other::--- I am member of the group lt-dv (verified with net rpc user info username). I returned to 3.0.11 and have no possibility to test right now.
The problem is still there in the brand new 3.0.13 release. So back to 3.0.11 which is ok.
temporarily reopening with 2 unconfirmed reports. Laurent, please attach a level 10 debug log from smbd. As as well the output from getfacl on the parent directory and file in question. Thanks.
I'm guessing this is related to the problem with some people's compiles not picking up POSIX ACL support in smbd. Jeremy.
(In reply to comment #11) samba 3.0.13 on SuSE 8.2 with ACLs now seems to be ok now. I tested the same actions as with the buggy 3.0.12 and now everything works fine, just as with the version 3.0.11. The samba 3.0.13 version was downloaded as a rpm from ftp.suse.com. Thomas.
original reporter says ok. No evidence to believe otherwise. CLosing again.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.