SOLVED ACLs Missing on Subfolders?

Status
Not open for further replies.

Elegant

Explorer
Joined
Aug 27, 2015
Messages
67
Hi guys,
I've just started mounting my CIFS shares on a Ubuntu Server and have noticed something quite troubling: the ACLs are missing on all my subfolders (eg: //FreeNAS/Users/Elegant)!

Subdirectory.png


They do appear on the base folder of the share however (eg: //FreeNAS/Users):

Base View.png


I'm not sure if there's a setting I've forgotten or what but this really frustrating. FreeNAS is set to use UNIX extensions and Ubuntu is setup to allow extended attributes and ACLs in /etc/fstab. This means that as user Elegant, I can enter the base folder but cannot enter my profile called Elegant. Any help as to what I'm missing would be greatly appreciated!
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
Hi guys,
I've just started mounting my CIFS shares on a Ubuntu Server and have noticed something quite troubling: the ACLs are missing on all my subfolders (eg: //FreeNAS/Users/Elegant)!

View attachment 12938

They do appear on the base folder of the share however (eg: //FreeNAS/Users):

View attachment 12937

I'm not sure if there's a setting I've forgotten or what but this really frustrating. FreeNAS is set to use UNIX extensions and Ubuntu is setup to allow extended attributes and ACLs in /etc/fstab. This means that as user Elegant, I can enter the base folder but cannot enter my profile called Elegant. Any help as to what I'm missing would be greatly appreciated!
Post output of "getfacl /mnt/<pool>/Users", "getfacl /mnt/<pool>/Users/Elegant", and "zfs get aclmode <pool>/<dataset>" for the dataset in which "//FreeNAS/Users" is located.
 

Elegant

Explorer
Joined
Aug 27, 2015
Messages
67
Post output of "getfacl /mnt/<pool>/Users", "getfacl /mnt/<pool>/Users/Elegant", and "zfs get aclmode <pool>/<dataset>" for the dataset in which "//FreeNAS/Users" is located.

Thanks for the quick reply, as requested I have captured the output and attached them below.

The ACL for Users:

ACL - Users.png


The ACL for Users/Elegant:

ACL - Elegant.png


The ZFS ACL Mode:

ZFS - ACL Mode.png
 
Last edited:

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
Thanks for the quick reply, as requested I have captured the output and attached them below.

The ACL for Users:

View attachment 12940

The ACL for Users/Elegant:

View attachment 12939

The ZFS ACL Mode:

View attachment 12942

Well... It looks like you've had some users or groups disappear since you set up the share. Entries like "90000006" indicate winbind's idmap range. You might want to make sure that AD is working properly (if you are using AD).

I'm not sure what's causing your issue, but I have noticed that you removed permissions from the "Owner@" special ACE. The isn't a problem for GAIA\Elegant in /mnt/tank/Users (because that directory is owned by "administrator"). However, it could be an issue in /mnt/tank/Users/Elegant, which is owned by GAIA\Elegant.

I think a good course of action is to recursively change the permissions of the dataset "Users" so that it is owned by "root:domain admins", then cycle the "apply default permissions" checkbox in your "users" share. Once you have done this, redo your permissions and do not delete the ACE for "root".

BTW, you don't actually have to enable ACL support on your Linux cifs client. I don't do it. Posix Draft ACLs are different than NFSv4 ACLs, and so it's possible you might run into some errors there (just a hunch).
 

Elegant

Explorer
Joined
Aug 27, 2015
Messages
67
Well... It looks like you've had some users or groups disappear since you set up the share. Entries like "90000006" indicate winbind's idmap range. You might want to make sure that AD is working properly (if you are using AD).

I'm not sure what's causing your issue, but I have noticed that you removed permissions from the "Owner@" special ACE. The isn't a problem for GAIA\Elegant in /mnt/tank/Users (because that directory is owned by "administrator"). However, it could be an issue in /mnt/tank/Users/Elegant, which is owned by GAIA\Elegant.

I think a good course of action is to recursively change the permissions of the dataset "Users" so that it is owned by "root:domain admins", then cycle the "apply default permissions" checkbox in your "users" share. Once you have done this, redo your permissions and do not delete the ACE for "root".

For a bit more insight, these entries were created using this guide on the forums by you for home directories on Windows. Which I now notice the warning caption so that could be a red flag...

If I'm not mistaken, when you use ADUC to create home directories it assigns the user who is running the ADUC process as the Owner overriding anything else. So, if 'John' used ADUC to create a home directory for user 'Jane', John is actually the Owner not Jane. Mind you, I could change the Owner back to 'root' every time I create a new user, it's no big deal but is this really correct? Don't get me wrong I can redo them with ease but in practice this would seem wrong no?

Maybe its be due to autorid using 20,000-90,000,000 yet CIFS uses 90,000,001-100,000,000? When I saw the CIFS idmap I really wondered how this would work on the client side. In fact, I'm still unsure about how the additional idmap range works into the mix when using a CIFS client.

BTW, you don't actually have to enable ACL support on your Linux cifs client. I don't do it. Posix Draft ACLs are different than NFSv4 ACLs, and so it's possible you might run into some errors there (just a hunch).

Disabling the ACL made no impact (specified 'noacl') but I will keep this in mind for testing now. Thanks!

PS: The CIFS client also complains about the service inode number but I've been ignoring this thus far.
 
Last edited:

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
For a bit more insight, these entries were created using this guide on the forums for home directories on Windows.
Hah! So I'm to blame. :D

If I'm not mistaken, when you use ADUC to create home directories it assigns the user who is running the ADUC process as the Owner overriding anything else.
For the most part, NFSv4 ACLs and NTFS ACLs are identical, but there are some differences. NFSv4 ACLS have the concept of 'special' ACEs (owner@, group@, everyone@), which are compatible with user, group, other in traditional posix mode bits. Windows doesn't have these. As a result samba has two different methods for translating these 'special' ACEs to make an NTFS ACL.

Method 1 - "nfsv4:mode=special". This translates the 'Special' ACE into an explicit NTFS ACE. For instance, the owner is "Bob" and owner@ has "full control", samba will present "Bob:full control" to Windows Clients. Samba will also show that "Bob" is the owner of the file.
Method 2: "nfsv4:mode=simple". Samba creates a non-inheriting ACE for the UID associated with owner@. Samba will also map the owner@ and group@ entries to inheriting "creator-owner" and "creator-group" NTFS ACEs.

FreeNAS defaults to Method 1. The side-effect of this is that deleting the NTFS Access Control Entry (bob in the above example) at the root of the share \\FreeNAS\Users will potentially affect the permissions of the owners of directories further down the tree. An additional side-effect of FreeNAS using "Method 1" is that the "creator-owner" NTFS ACE doesn't work (there's probably a reason why it has been deprecated). This is a fundamental defect in my how-to guide, which was largely based a samba project wiki entry.

So, if 'John' used ADUC to create a home directory for user 'Jane', John is actually the Owner not Jane. Mind you, I could change the Owner back to 'root' every time I create a new user, it's no big deal but is this really correct? Don't get me wrong I can redo them with ease but in practice this would seem wrong no?
I see this as a problem as well. I need to look into it and experiment more. If this is the case, you could probably create a powershell script to automate the process. As things currently stand, it may be a better idea to use the traditional [homes] shares with AD. [homes] will dynamically generate unique user shares as users authenticate to the server. You might be able to set it as the home directory in ADUC, but it seems like you might have an interesting race condition (I believe home directories can be accessed via \\freenas\homes as well as \\freenas\bob). Once again, I'll need time to poke around and see what works. You might also be able to use group policy preferences to have windows automatically map \\freenas\%USERNAME%. Home shares by default have a share definition access control set so that users can only access their own home shares.

So tl;dr I put a disclaimer at the top of my guide.

Maybe its be due to autorid using 20,000-90,000,000 yet CIFS uses 90,000,001-100,000,000? When I saw the CIFS idmap I really wondered how this would work on the client side.
There are two idmap ranges and backends for a domain-joined FreeNAS server. One is backed by a tdb file and contains user/group mappings for Windows built-in / well-known SIDS. The other is for your domain users / groups. I simplify things by using the same idmap settings for all domain joined Linux servers. Since idmap_rid is deterministic this has the effect of providing the same UIDs and GIDs for all domain users and groups on all *nix servers.

In fact, I'm still unsure about how the additional idmap range works into the mix when using a CIFS client.
It should 'just work'.


Disabling the ACL made no impact (specified 'noacl') but I will keep this in mind for testing now. Thanks!

PS: The CIFS client also complains about the service inode number but I've been ignoring this thus far.
 

Elegant

Explorer
Joined
Aug 27, 2015
Messages
67
FreeNAS defaults to Method 1. The side-effect of this is that deleting the NTFS Access Control Entry (bob in the above example) at the root of the share \\FreeNAS\Users will potentially affect the permissions of the owners of directories further down the tree. An additional side-effect of FreeNAS using "Method 1" is that the "creator-owner" NTFS ACE doesn't work (there's probably a reason why it has been deprecated). This is a fundamental defect in my how-to guide, which was largely based a samba project wiki entry.

So from what I've gathered then, the solution is to switch the share from using "nfsv4:mode=special" to "nfsv4:mode=simple" (and abolish CREATOR OWNER), which in this case would make sense since that is the issue. I can confirm that making any subfolder owned by the administrator again solves this issue so we are on the right track.

Now, I would expect this to mean that once I've applied this change, restarted CIFS as well as FreeNAS itself that this would kick in. It seems it does not, if I go to the root of my CIFS share (owned by the administrator) and create a new folder (on either Windows or Ubuntu), I am still the owner of that folder. Upon further inspection, my smb.conf now contains both options for nfsv4:mode with "special" leading since it's the FreeNAS default and the additional entry to switch to "simple" added as an auxiliary at the end. This could become a big issue if it's ignoring the second entry to switch to simple.

EDIT: This is NOT the solution; see below.
 
Last edited:

Elegant

Explorer
Joined
Aug 27, 2015
Messages
67
Thank you anodos, you pointed me in the right direction as I looked into Samba quite a bit more and found exactly how to solve this particular issue. nfs4:mode makes no impact on this afterall. What needs to happen is the following:

1. Add acl_xattr to VFS Objects for the CIFS share.
2. Enter the following as Auxiliary Parameters:
Code:
inherit owner = yes
acl group control = yes


You do not necessarily need the second parameter but it would make sense in my eyes to allow this if you intend for owner group to have control over permissions. This combined with your guide anodos allows for me to maintain my current permissions and allow access to shares on linux. It should be noted that the user still has access to their home directory as ADUC will provide that folder with Full control.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
Thank you anodos, you pointed me in the right direction as I looked into Samba quite a bit more and found exactly how to solve this particular issue. nfs4:mode makes no impact on this afterall. What needs to happen is the following:

1. Add acl_xattr to VFS Objects for the CIFS share.
2. Enter the following as Auxiliary Parameters:
Code:
inherit owner = yes
acl group control = yes


You do not necessarily need the second parameter but it would make sense in my eyes to allow this if you intend for owner group to have control over permissions. This combined with your guide anodos allows for me to maintain my current permissions and allow access to shares on linux. It should be noted that the user still has access to their home directory as ADUC will provide that folder with Full control.

Do note that you're adding an additional ACL layer on top of the existing ACL layer. This might end up causing some interesting interactions. If it does cause a problem, you may want to look into disabling "zfsacl". You can do this by adding a "vfs objects" line in your share auxiliary parameters (i.e. "vfs objects = zfs_space acl_xattr"). If you go this route, you may also wish to change permissions type for the dataset to "unix".

I believe on large datasets you may also encounter performance problems with acl_xattr on FreeBSD (due to operations related to xattrs being rather slow).

Anyway, I'm glad you found something that works for you.
 

Elegant

Explorer
Joined
Aug 27, 2015
Messages
67
I don't intended to change the permissions for the dataset to "unix" as I do want to manage things with Windows (we'll see how that goes). As for using zfs_space that won't be necessary as that is automatically applied behind the scenes by Samba (as confirmed by the smb4.conf file) when using acl_xattr.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
I don't intended to change the permissions for the dataset to "unix" as I do want to manage things with Windows (we'll see how that goes). As for using zfs_space that won't be necessary as that is automatically applied behind the scenes by Samba (as confirmed by the smb4.conf file) when using acl_xattr.

The reason why I suggested the "vfs objects" line was to disable the "zfsacl" vfs object, which is hard-coded into the smb4.conf file. Samba will only interpret the last "vfs objects" line in a share definition, and so adding this will effectively remove the hard-coded parameter.
 
Status
Not open for further replies.
Top