samba - Feb 2022 - simple permission scheme messed up with unwanted ACLs - how to fix?

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 
are different,

     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 
say no.

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
> user::rw-
> user:jane:rw-
> group::r--
> group:users:r--
> mask::rw-
> other::r--
> 
> 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 
> 2:4.13.17~dfsg-0ubuntu0.21.04.1.
> 
> 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
>

Hi Patrick,

Thanks for your answer.

On 10-02-2022 23:35, Patrick Goetz via samba wrote:
> 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.
Actually, that's how it used to be: the linux machines had their /home 
mounted on the server with NFS4, with Kerberos authentication and all. 
But NFS has its own problems - my guess is that it was too complicated 
to get the Macs to connect to NFS, or that the user level security was a 
problem, or the need to keep local userIDs in sync - I'm not sure, it's 
a long time ago. I don't think we even tried to setup NFS4/Kerberos 
authentication on any Mac. And as most OSs have password managers 
built-in now, the great advantage of Kerberos for single sign-on (which 
to end users just means "not having to remember any extra passwords") 
has greatly diminished, IMHO.
>  ??? ea support = no
> applies to attributes (not ACLs) and consequently won't help you, 
Thanks. (It probably shows how confused I was ;-)
> Are you using extended ACLs on your file server?
They are there, but I'm not using any.

[...]

Thanks for your explanation - helped to see things in perspective and I 
guess I'm fine with the current settings for now.

Regarding my problem:
> 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.
... A few hours after my post, I found yet another ACL option, namely 
"fruit:nfs_aces". I set this to "no" and since then, no more
ACLs have
been added to any files. So my guess is that vfs_fruit was the culprit: 
"A global option whether support for querying and modifying the UNIX 
mode of directory entries via NFS ACEs is enabled, default yes."

I still don't know why these apple computers were changing ACLs anyway. 
But I guess that's a question for an Apple forum, not this list ;-)

Best regards,

Valentijn
-- 
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  v.sessink at openoffice.nl  +31(0)20-4214059