After updating from 3.0.11 to 3.0.12 the ACL feature is not working properly
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
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:
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.
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
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
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
getfacl acl-bug/New\ Text\ Document.txt
# file: acl-bug/New\040Text\040Document.txt
# owner: jerry
# group: 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
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
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.
(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.
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.