[Samba] ACL misbehavior moving from POSIX ACL -> acl_xattr

Wes Deviers wdevie at hrcsb.org
Wed Sep 16 11:38:13 MDT 2009

On Wednesday 16 September 2009 12:56:11 pm Jeremy Allison wrote:
> On Wed, Sep 16, 2009 at 11:18:58AM -0400, Wes Deviers wrote:
> > 
> > How can I insist that Samba use the vfs object ACL module, instead of the 
> > POSIX acls?
> You can't at the moment. Samba still requires the incoming
> ACL to be converted into an underlying file system ACL, as
> the underlying filesystem still must have the final decision
> on access decisions. The NT acl is stored as an "extra" layer
> of ACL metadata on top of this, which is also consulted.
> You could slot in a "null" ACL module underneath the acl_xattr
> layer that always allowed acl set and returned an "allow everyone"
> acl on read, but that isn't coded yet (shouldn't be too hard
> though).
> Currently if you want "native" NT ACLs only I suggest you
> use the NFSv4 module, which is pretty close to native Windows
> ACLs. 
> Jeremy


As always, thank you for your reply!

I'm confused now.  I have a VirtualBox instance set up identically, except 
that the underlying filesystem (ext3) has never had -o acl set on it, only -o 
user_xattr.  What I've been doing, which is dangerous but effective, is setting 
file creation mode to 666 and letting the Samba VFS ACL layer take care of 
everything.  That's worked.

As I understood the system under the new VFS module, Samba does its internal 
ACL checks and if those pass, it then attempts file operations as normal, which 
may or may not work depending on the "real" file permissions.  If I have POSIX 
ACLs applied, those also have to agree; otherwise, the normal UGO permissions 
are what must work.  I'm clear through this part.

Where I'm confused is that on a machine that I do have working, there is no 
POSIX ACL support, but the Samba VFS layer works brilliantly.  Inheritance, 
take ownership, everything works on the VFS layer without needing any POSIX 

On the "old" server, I've taken a machine that was previously storing the 
Samba ACL metadata as POSIX mappings, pulled the POSIX mappings out from under 
it, and tried to get it to use the VFS module exclusively.  All files/dirs are 
666 or 777.  According to my reading, since there are no POSIX extended ACLs, 
if the VFS layer "passes" an access, then it only should be compared against 
the standard UGO permissions.  Testing on a virtual machine seemed to confirm 

I think you read my question as: "Why am I denied access because of my POSIX 
ACLs, even though the VFS ACL module is in place?"  I'm clear on what's 
involved there, I think.  What I was *trying* to make my question:

"Since I've turned POSIX ACLs *off* at the filesystem layer by removing the ACL 
mount option, why does Samba continue to want to store it's ACL metadata in 
the POSIX ACL layer instead of the VFS module?"  So, no Linux ACLs, and a+rwx 
on all files/directories.  It works on one machine....  : (

Or, alternately, "Does Samba, with vfs object = acl_xattr, store ACLs both as 
a user_xattr AND an ext3 ACL at the same time?"  My limited testing shows that 
*not* to be the case, but I'm certainly not the expert.

Thanks again!


More information about the samba mailing list