POSIX and Windows ACLs

[Elegant]

Hey guys,
I have a working setup right now where I have my home drives accessible on Linux and Windows through AD. Lately, I had a minor issue and I was wondering how best to tackle it. According to my current mode for my 'User' storage I have it set as 070 (---rwx---) this is of course greyed out in FreeNAS since this is a Windows share not a Unix share.

Now, this isn't really a problem at first because Linux understands my ACLs and the permissions work perfectly. However, I had an issue where some tasks in Linux are not a fan of seeing the 070 and that the file is not owned by the current user. My though was simple, let's just add uid=${UID},forceuid and set it to the proper user since my ACLs will still govern the files. Great, but what about the 070 permissions? So I thought I'd add 4 lines to the end of my share:

Code:

inherit acls = yes
inherit owner = yes
acl group control = yes
access based share enum = yes
create mask = 0777
force create mode = 0600
directory mask = 0777
force directory mode = 0700 

This made sense to me but the permissions do not take effect. Is this due to the "Apply Mode" being checked? I don't really want to start screwing with something I do not know enough about. My goal is to get that 070 to read 600 for the files in my home directory share without disrupting my ACLs. Thanks!

 

[anodos]

Changing posix mode bits on "windows" datasets isn't permitted. Any such operation will fail. I think you can achieve what you want through manipulating ACLs (no need to add auxiliary parameters to the Samba share).
Post output of getfacl /path/to/share

 

[Elegant]

Attached is my getfacl for the share. Although the administrator is the owner it is due to inheritance. The unofficial owner would be the intended user who I would set with uid=${UID},forceuid. Thanks!

 

[Elegant]

After researching a bit more I now understand my issue and I doubt there is a solution. What I want to do is have a Windows ACL and a POSIX ACL for each file. I suppose one way would be to create an entire symlink share but that seems wrong. My issue is that the POSIX bits are not correct for some LInux programs to be willing to read them despite the fact that the Windows ACLs are working fine and allowing the access if the program tried.

I don't think I'll see a solution to this anytime soon given they that are two different systems. Thanks!

 

[anodos]

After researching a bit more I now understand my issue and I doubt there is a solution. What I want to do is have a Windows ACL and a POSIX ACL for each file. I suppose one way would be to create an entire symlink share but that seems wrong. My issue is that the POSIX bits are not correct for some LInux programs to be willing to read them despite the fact that the Windows ACLs are working fine and allowing the access if the program tried.

I don't think I'll see a solution to this anytime soon given they that are two different systems. Thanks!

Lost track of this thread. If you need 770 on a share, use find /mnt/tank/users/ -exec setfacl <parameters> to set "full control" for owner@ with the proper inheritance bits set. This should exactly replicate 770 in your situation while preserving the nontrivial aces.

Sorry for the hand-waving $parameters bit. I can't recall the exact syntax off the top of my head, but some googling should put you on the right path.

I've written some about ACLs here: https://wiki.freenas.org/index.php/Methods_For_Fine-Tuning_Samba_Permissions

 

[Elegant]

Lost track of this thread. If you need 770 on a share, use find /mnt/tank/users/ -exec setfacl <parameters> to set "full control" for owner@ with the proper inheritance bits set. This should exactly replicate 770 in your situation while preserving the nontrivial aces.

Sorry for the hand-waving $parameters bit. I can't recall the exact syntax off the top of my head, but some googling should put you on the right path.

I've written some about ACLs here: https://wiki.freenas.org/index.php/Methods_For_Fine-Tuning_Samba_Permissions

No worries, I read up a bit more on setfacl. I added in my flags for owner@ which was missing entirely (hence the lack of user permissions). I added the fd flags to the owner@ ACE but it is not applying to sub directories and files when I create files in Windows. If I create the files in FreeNAS everything inherits correctly; I have since created a new storage and created a new share to ensure I am working with something fresh.

Any thoughts on how to make Windows obey the new ACLs? It doesn't seem to be a fan.

 

[anodos]

No worries, I read up a bit more on setfacl. I added in my flags for owner@ which was missing entirely (hence the lack of user permissions). I added the fd flags to the owner@ ACE but it is not applying to sub directories and files when I create files in Windows.[/cmd]

You can't just apply it to the root of the directory and expect it to propagate. If you add the ACL to /mnt/Tank/Share/foo, only new files and folders under /mnt/Tank/Share/foo will have the new inheriting ACL. Files created under, for instance, /mnt/Tank/Share/foo/bar/ will not inherit the new ACL. That's the reason why I said you will need to use find.

For example, something like:
find /mnt/Tank/Share/ -type d -exec setfacl -m owner@:full_set:fd:allow {} \;
find /mnt/Tank/Share/ -type f -exec setfacl -m owner@:full_set:fd:allow {} \;

Of course, test before running a command like that across all your data, and grab a cup of coffee because it might take a while to complete (use a proper SSH client - not the webshell!).

 

[Elegant]

I'm doing this through my VM and testing on a new share with nothing on it; that's where I'm noticing the issue. I grasp that if you I simply type find /mnt/Tank/Share/ -exec setfacl -m u:owner@:full_set:fd:allow {} \; that all current files and sub-directories within will not inherit the new ACL without propagating (apply recursively).

Let's say I add the ACL to /mnt/Tank/Share/foo and then I explore to directory foo on Windows. If I create a file or directory within foo I should expect that file to inherit the ACL from foo. The issue is that this is not the case, nothing created within foo is inheriting the owner@.

In my last attachment, Test.txt was created after /mnt/tank/Test was assigned owner@ and it did inherit. The same issue occurs if I did that in /mnt/tank/Test/foo where foo also receives @owner and then Test.txt is created on Windows. Test.txt does inherit owner@ in either case despite the ACLs.

 

[anodos]

I'm doing this through my VM and testing on a new share with nothing on it; that's where I'm noticing the issue. I grasp that if you I simply type find /mnt/Tank/Share/ -exec setfacl -m u:owner@:full_set:fd:allow {} \; that all current files and sub-directories within will not inherit the new ACL without propagating (apply recursively).

Let's say I add the ACL to /mnt/Tank/Share/foo and then I explore to directory foo on Windows. If I create a file or directory within foo I should expect that file to inherit the ACL from foo. The issue is that this is not the case, nothing created within foo is inheriting the owner@.

In my last attachment, Test.txt was created after /mnt/tank/Test was assigned owner@ and it did inherit. The same issue occurs if I did that in /mnt/tank/Test/foo where foo also receives @owner and then Test.txt is created on Windows. Test.txt does inherit owner@ in either case despite the ACLs.

I fixed the commands in my previous post (they were wrong), and verified that they inherited correctly on new files / folders created via Windows Explorer (they did). ACE ordering can be an issue in samba. When you view your share definition in /usr/local/etc/smb4.conf file, you should see the entry zfsacl:acesort = dontcare. It is possible that this doesn't work quite right. This is the reason why it's generally a good idea to only manage ACLs from windows or through smbcacls on a *nix system with samba installed... and don't remove the ACE for owner@ or group@.

That said, recovery from the FreeNAS webui is fairly simple.

1. Recursively reset permissions on the dataset through Storage -> Volumes -> <dataset>
2. Check "apply default permission" through Sharing -> Windows (SMB) Shares -> <your share>

Do note that owner@, group@, and everyone@ exist to provide compatibility with unix mode bits, and are a key difference between NTFS ACLs and NFSv4 ACLs. It's also important to understand that "everyone@" is NOT equivalent to unix "other". Everyone@ means literally "everyone" including the owner and owning group.

For more information regarding owner@, group@, and everyone@, consult RFC7530, Section 6.3.2 - 6.4.2.

So when you remove these ACEs you are in a sense removing a unix compatibility feature and it shouldn't be surprising that unix processes don't like it. :D

That said, some consideration should be given to how freely you give out permissions to modify ACLs. full_set and modify_set are both equivalent to rwx, but in the latter case users shouldn't be able to modify (i.e. break) ACLs.

A good default might be to grant owner@ and group@ read,write,modify / modify_set, then use non-trivial ACLs to define permissions for the share (i.e. add your AD groups). Removing everyone@ should be fine. I've used this sort of setup for a number of years without issue. Unix processes are happy and Windows is happy.