Samba – How to stop Samba from writing extended ACLs

access-control-listsamba

Is there any configuration option to stop Samba from writing extended ACLs for newly created files? I only found nt acl support but this seems to disable support for permissions completely. I want Samba to behave as if my filesystem didn't support ACLs.

Best Answer

This answer does not really solve the problem, but as nobody else answered anything for years, I'll share my experience hoping it might help someone. Please correct me if I am wrong.

There doesn't seem to be an easy way to do that. With "easy", I mean, not with a standard configuration option. It probably requires recompiling samba with the option --with-acl-support=no, and even recompiling the kernel.

I am saying this after testing by explicitly disabling every single acl and xattr option in the samba configuration.

The easiest solution would probably be to disable ACLs on the server and the file system of the share. But that is also not easy.

I did manage to disable ACLs on XFS, by formatting the partition as mkfs.xfs -m crc=0 /dev/mydev1, and mounting it with mount -t xfs -o noattr2 /dev/mydev1 /mnt/mymount. But surprisingly the ACLs can still be stored!

The reason behind this, seems to be that kernels newer than 2.6 come already with the ACL support pre-compiled. Try running grep -i acl /boot/config-$(uname -r) and you'll see plenty of entries, including "CONFIG_CIFS_ACL" with values "=y", which means that they are hard-coded into the kernel, and cannot be disabled.

So, either recompile samba and/or the kernel, or as we did, learn to live with it and eventually adopt the ACL policy.

Related Solutions

Linux – Mac OS X clients cannot see extended ACLs through samba or netatalk on a debian server

Try this workaround:

Add

acl check permissions = no

to [global] because of how Darwin ACLs are closer to Windows ACLs instead of POSIX ACLs.

Sources:

Linux – How to set Linux Default ACLs differently for directories and files

Well, but your example does exactly what you want ;)

Look at the second one:

overt htdocs # setfacl -dm u:apache:rx .
overt htdocs # touch blah.txt
overt htdocs # getfacl blah.txt
# file: blah.txt
# owner: root
# group: root
user::r--
user:apache:r-x                 #effective:r--
group::r--
mask::r--
other::r--

The important line is:

user:apache:r-x #effective:r--

Even though acl is set to r-x it is effectively r-- for files. It is because of the mask.

And the mask will be always only rw- for files if the user created it with the rw- permissions for user. (I'm not 100% sure but mask cannot be less restrictive then the basic permissions).

So effectively you get r-- for files and r-x for directories.
Because created directories will have user:r-x -> mask will be r-x -> effective permission will be r-x.
For files: they will have r-- so mask will be r-- and effective permissions for ACLs will be r--, too. (If you create a file and give it a user::r-x permissions, then mask will be modified and users form acl's will get the x, too)

Best Answer

Related Solutions

Linux – Mac OS X clients cannot see extended ACLs through samba or netatalk on a debian server

Linux – How to set Linux Default ACLs differently for directories and files

Related Topic