ACL headaches after upgrade

[Brad303]

Hi guys,

I just upgraded to FreeNAS-9.3-STABLE-201602031011. I don't know what 9.3 version I was running before, but the "update available" emails were pestering me for months and the first bug in the changelog was #7376.

After the upgrade, I was unable to mv or rsync files to my datasets over NFS. Both would error out with "operation not permitted". I didn't change the permissions on the directories, so it must have been something that changed with the update.

I was prompted by a gui warning to do a `zfs upgrade` on 2 of my 3 pools, although why it wasn't all 3 I don't know. That warning wasn't there previously.

I never noticed it before, but mount now shows my ZFS pools as being mounted with 'nfsv4acls':

Code:

FatZ on /mnt/FatZ (zfs, local, nfsv4acls)

Additionally, some of my datasets have the '+' which indicates ACLs:

Code:

drwxrwxr-x+ 58 nobody  windows  58 Feb 10 21:25 TV

If I use `setfacl -b` to clear the ACLs on the destination directory, mv and rsync work as they did previous to the upgrade. Currently, setfacl is missing the recursive option, so it's an exercise in frustration to recursively clear all the ACLs in a large dataset.

That also begs the question of how the ACLs were created in the first place. Why do some datasets have the ACLs, but some don't? Does it have anything to do with the "Permission Type" or "Share type" of the pool?

Is there a way to turn off the 'nfsv4acls' mount option on the pool? I'm assuming not as ZFS uses nfsv4 ACLs internally.

Barring that, how do I clear the ACLs recursively? Can it be done via the GUI?

Thanks,

Brad

 

[anodos]

Hi guys,

I just upgraded to FreeNAS-9.3-STABLE-201602031011. I don't know what 9.3 version I was running before, but the "update available" emails were pestering me for months and the first bug in the changelog was #7376.

After the upgrade, I was unable to mv or rsync files to my datasets over NFS. Both would error out with "operation not permitted". I didn't change the permissions on the directories, so it must have been something that changed with the update.

I was prompted by a gui warning to do a `zfs upgrade` on 2 of my 3 pools, although why it wasn't all 3 I don't know. That warning wasn't there previously.

I never noticed it before, but mount now shows my ZFS pools as being mounted with 'nfsv4acls':

Code:

FatZ on /mnt/FatZ (zfs, local, nfsv4acls)

Additionally, some of my datasets have the '+' which indicates ACLs:

Code:

drwxrwxr-x+ 58 nobody  windows  58 Feb 10 21:25 TV

If I use `setfacl -b` to clear the ACLs on the destination directory, mv and rsync work as they did previous to the upgrade. Currently, setfacl is missing the recursive option, so it's an exercise in frustration to recursively clear all the ACLs in a large dataset.

That also begs the question of how the ACLs were created in the first place. Why do some datasets have the ACLs, but some don't? Does it have anything to do with the "Permission Type" or "Share type" of the pool?

Is there a way to turn off the 'nfsv4acls' mount option on the pool? I'm assuming not as ZFS uses nfsv4 ACLs internally.

Barring that, how do I clear the ACLs recursively? Can it be done via the GUI?

Thanks,

Brad

"Windows" permissions type uses ACLs. Changing permissions type to "unix" then recursively applying a user/group change on a dataset through the webgui should be enough to remove the ACLs.

Otherwise you can use "find" and "setfacl" to reset acls. e.g. "find /mnt/<pool>/<dataset> -exec setfacl -b {} \;"

 

[Brad303]

Thanks for the reply.

Unfortunately, I can't get the "unix" perm type to stick. I've changed it in the GUI, ticked the recursive box and changed the user & group. While the user and group ownership actually change, the '+' is still next to everything in the dataset.

The `find /foo exec` worked, although there should be a way to undo the "damage" caused by selecting "Windows" permissions in the GUI.

Is there a reference to the difference between "Windows permissions" and "Windows share type"?

 

[anodos]

Thanks for the reply.

Unfortunately, I can't get the "unix" perm type to stick. I've changed it in the GUI, ticked the recursive box and changed the user & group. While the user and group ownership actually change, the '+' is still next to everything in the dataset.

The `find /foo exec` worked, although there should be a way to undo the "damage" caused by selecting "Windows" permissions in the GUI.

Is there a reference to the difference between "Windows permissions" and "Windows share type"?

The UI options are documented on doc.freenas.org
I wouldn't characterize it as 'damage'. The changes that it makes are specifically to prevent people from wrecking permissions on their CIFS shares.

 

[Brad303]

I must have been looking at old docs, as I see the details there now.

I don't know if I found a bug, but there was no way I could find to disable the ACLs from the GUI once they were enabled. The docs say it should revert, but that wasn't the case for me.

As to "damage", I was referring to the fact that my NFS & CIFS shares played well together until the upgrade. After that the permissions prohibited me from doing what I was doing before.

Yes, I understand that finer-grained permissions are handy in various situations, but in this case, it was very bewildering and frustrating. And I've been running FreeBSD systems for decades.