[Samba] simple permission scheme messed up with unwanted ACLs - how to fix?
pgoetz at math.utexas.edu
Thu Feb 10 22:35:19 UTC 2022
I struggled with this too, as it's kind of confusing. Samba works behind
the scenes to keep Windows and linux permissions in sync, assuming you
have POSIX ACLs turned on.
This is an aside, but unless you're running a domain controller it's not
clear why you're using Samba at all if you don't have any Windows
machines. It's easier to use NFS for a linux/Mac environment. That
said, and assuming you're talking about ACLs and not attributes, which
ea support = no
applies to attributes (not ACLs) and consequently won't help you,
although it won't hurt you either if you don't have any Windows
machines. This defaults to yes to support Windows file servers and
archive bits on files (e.g. setting a file to read-only on Windows).
Are you using extended ACLs on your file server?
inherit acl = yes
just insures that default ACLs on parent folders are honored in the
linux filesystem. For linux admins the slightly jarring thing about
this is it will set all the file/folder unix permissions to 0777 to
guarantee that ACLs are inherited. If you're not using ACLs, you can
Keep in mind that Samba is designed to allow Windows machines to use and
store files on a linux filesystem. So when a Windows user saves a file
to your linux server, Samba has to decide what the linux permissions
will be on this file. Think of create mask, as in
create mask = 0770
as equivalent to umask in linux. With that in mind,
inherit permissions = yes
turns off create mask and just has files and directories inherit the
permissions their parent directories have. Given the simple security
model you have, either of these should work for you.
You obviously don't care about nt acl support, but it doesn't hurt to
leave it at the default, which is yes.
If that's insufficient, provide us with an example of what you're
talking about in addition to the [global] section of your smb.conf file.
On 2/10/22 07:19, Valentijn Sessink via samba wrote:
> Hello list,
> I'm trying to have /home/users/ and everything below it
> readable/writable for every mac/linux user in a small office network
> based on an Ubuntu Linux server; but since a couple of weeks, extra ACLs
> seem to pop up from Apple users. What is the best way to setup this
> rather simple permission scheme?
> I found so many smb.conf settings that I don't know which ones are
> vital. A rough guess is that just setting "ea support = no" would be
> enough, but I'm not even sure. I found:
> - ea support
> - inherit acls (would that help?)
> - inherit owner (probably unnecessary because "force group"?)
> - inherit permissions (Help, I just read inherit acls and now what does
> *this* do?)
> - nt acl support (should that be "no" because I want it the other way?)
> Which setting(s) would serve me best? There are no Windows machines
> attached so I'm probably not helped with the Windows ACL scheme because,
> as far as I understand, I'd need a Windows machine to fix any file
> rights afterwards.
> * Setup *
> What I'm seeing, with getfacl, is:
> # file: Jane/Meeting/Draft/20220205 design.odt
> # owner: jane
> # group: users
> This is rather unwanted, as the share has:
> force group = users
> force directory mode = 2770
> force create mode = 0660
> directory mask = 2770
> create mode = 0660
> writable = yes
> path = /home/users
> valid users = @users
> These files are written by MacOS and obviously, OSX makes use of the
> extended ACL possibilities of the Linux file system.
> Server is ubuntu 20.04, Ubuntu samba version
> I did read
> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_POSIX_ACLs and
> https://wiki.samba.org/index.php/NFS4_ACL_overview; I also tried to find
> my way in smb.conf but I just don't know which option does what. I'm
> just trying to find a way to have every file in /home/users be
> readable/writable for everyone in @users.
> There are no Windows machines in this network, it's all MacOS and Linux.
> I'd rather not have MacOS mess with permissions, as my end users are
> unaware of stuff like "file permissions" and "inheritance" anyway, so
> files that are unreadable or unwritable for them are just signs of a
> failing server. (And in a way, I agree).
> Further smb.conf settings that could be of interest:
> workgroup = office
> unix extensions = yes
> vfs objects = fruit streams_xattr
> fruit:metadata = stream
> veto files = /.DS_Store/._.DS_Store/
> security = user
> mangled names = illegal
More information about the samba