Permissions wrong after upgrade

[mpfusion]

I upgraded from FreeNAS-11.1-U4 to FreeNAS-11.2-U2.1 and now the permissions are wrong on one dataset. I have two datasets, configured exactly the same (as far as I can tell):

Code:

NFS share
---------

Maproot User: root
Maproot Group: wheel

Dataset Options
---------------

Share Type: Unix

Dataset Permissions:
ACL Type: Unix

However, the permissions are different on both datasets:

Code:

datasetA:

$ umask 002
002

$ touch foo; ls -l foo
-rwxrwxr-x 1 mp xxx 0 2019-02-28 17:06 foo

change to datasetB:

$ umask 002
002

$ touch bar; ls -l bar
-rw-rw-r-- 1 mp xxx 0 2019-02-28 17:08 bar

Why is the execute bit set on datasetA regardless of the same umask? Both datasets are mounted with the “default” mount options with NFS.

OS Version: FreeNAS-11.2-U2.1
Processor: Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz (8 cores)
Memory: 192 GiB

 

[mpfusion]

OK, it appears that ACLs are active on the dataset. The ls -l listing contains a + appended after the permissions for all files in datasetA. This is not the case on datasetB.

How to remove the ACLs on all files/directories on the dataset?

 

[KrisBee]

Use getfacl on your datasets to see what ACL/ACEs maybe set. Also check values of the aclmode/aclinherit properties on the datasets. You may need to use setfacl -b to remove any unwanted ACL, but check the man pages as I'm not sure there is a recursive flag for this command so you could for example pipe the output of a suitable find command to setfacl -b.

 

[mpfusion]

You may need to use setfacl -b to remove any unwanted ACL, but check the man pages as I'm not sure there is a recursive flag for this command so you could for example pipe the output of a suitable find command to setfacl -b.

I tried that from the clients, didn't work. Nothing changed. But now did a few tests on the FreeNAS box itself and it seems to work. Now I've just ran a find <dir> -type f -exec setfacl -b {} \+; find <dir> -type d -exec setfacl -b {} \+. And that seems to have worked. So the issue was an ACL set on the freenas box that the clients couldn't change via NFS.

Thanks for the nudge in the right direction.

However, FreeNAS shouldn't mess with the ACLs on an upgrade IMO. It breaks people's systems.

 

[KrisBee]

Likely your NFS client only supported POSIX ACLs, so has to be corrected on FreeNAS side. So was this a bug? Currently, in FN11.2-U.2 if you switch dataset share type from NFS to Windows and back to NFS again, the default windows ACL is not removed. Don't know if your case is related.

 

[mpfusion]

Likely your NFS client only supported POSIX ACLs, so has to be corrected on FreeNAS side.

I have no idea. I never activated or used ACLs.

So was this a bug?

I'd call it a bug, yes. Upgrading shouldn't mess up permissions. But as I share a single dataset with NFS and CIFS, which is unsupported by FreeNAS I didn't report it.

Currently, in FN11.2-U.2 if you switch dataset share type from NFS to Windows and back to NFS again, the default windows ACL is not removed. Don't know if your case is related.

When I first noticed the issue the share type was set to Windows instead of Unix. So I suspect the upgrade changed the share type. When trying to find out what's wrong I changed it back to Unix because that's where it was before upgrading. And I just learned that resetting it doesn't restore the old behaviour, but instead one has to remove the ACLs manually.

 

[KrisBee]

This is the same bug. The more people who report it the better. Currently if you create a CIFS share the "default perms" box is autochecked but only visible if "advanced mode" is selected on the share create/edit screen. The unsuspecting user may not release the dataset perms share type is also automatically set to windows irrespective of which share type was originally set on the dataset.

 

[mpfusion]

This is the same bug.

The same bug as which one? Did you forget to link to the bug?

The more people who report it the better. Currently if you create a CIFS share the "default perms" box is autochecked but only visible if "advanced mode" is selected on the share create/edit screen. The unsuspecting user may not release the dataset perms share type is also automatically set to windows irrespective of which share type was originally set on the dataset.

I have not created a CIFS share after the upgrade. I've created the CIFS share four years ago and only upgraded the FreeNAS box every once in a while. And this upgrade changed the ACLs which was unexpected. But apparently it's a known issue. I'll gladly add myself to the *me too* list if you share the ticket number.

 

[KrisBee]

It was #76557 , but after checking I see they closed the issue saying the old behaviour was wrong and the new is correct. Personally I don't get this one at all. https://redmine.ixsystems.com/issues/76557

 

[mpfusion]

Yes, that seems to be exactly the problem I was facing. I'd definitely call it a bug. But as I'm running an unsupported setup, have found a workaround and the fact that they closed it as “works as designed”, I'm not going to pursue discussing the validity of that bug report and just hope future upgrades run smooth and I don't have messed up permissions after every upgrade.

Thanks for your help.