Permission/ACL problems after converting one Windows dataset to Unix

[rudds]

My FreeNAS 11.2-U7 machine has a primary RAIDZ1 pool with a handful of datasets, and also a secondary striped SSD that I use for disposable scratch space.

I intended all of these datasets to be set to the Unix share type in the web UI, but found yesterday that I must have set the SSD dataset to Windows when I created it, which was causing some permission problems when copying files to it. I changed the SSD to the Unix type, assuming the change would only affect that dataset (and since it's disposable I planned to just destroy/recreate it in the event of any issues) but this is where bigger problems started.

Somehow this caused all of the datasets on my primary pool to be converted to the Windows share type (??) according to the web UI, and every file across all of them took on ACL properties; this was apparent when they all became marked with a + sign according to ls -la and I started to have a big range of permission problems accessing them. After doing some searches here and elsewhere, I did the following:

• converted all the datasets back to Unix share type
• purged ACLs with find /mnt/<pool>/<dataset> | setfacl -b
• confirmed the ZFS property 'aclmode' is set to 'passthrough' on each dataset
• ran recursive chown/chmod on each dataset to make sure ownership and permissions are what they should be

While I can now work with files as root in a shell without issue, Windows is still telling me I don't have permission to access the SMB shares pointing at the primary datasets even though I'm using the credentials of the account that owns the dataset/files. Additionally, jails that use mount points on those datasets (Plex, et al) are all throwing various 'permission denied' errors and are unable to access any of the relevant files as well.

What can I do next to fix this? It feels like all the permissions have been reset properly but obviously I've missed something fairly major. (It's somewhat tempting to upgrade to 11.3 since I know it has new tools to manage ACLs, but I usually prefer to wait for a couple of update releases after a major version before upgrading.)

 

[rudds]

OK, I've now found that all datasets across all pools are converting back to the Windows share type (and a test dataset I created from a shell on an external drive for testing also defaulted to Windows), even after I explicitly set them to Unix. Is this something that's happening on the FreeNAS end? Or could Windows somehow be doing it when I try to map network drives? I'm baffled by this behavior.

 

[KrisBee]

I don't know about existing datasets, but IIRC in FreeNAS 11.2-U7 if a newly created dataset that is initially "unix share type" is then shared via SMB with the "default permissions" option set, the dataset then becomes a "windows share type" with its "aclmode" property set to "restricted". That should be easy enough to check/test.

I seem to remember FreeNAS 11.2-U7 GUI does not handle switching a dataset back and forth between "unix share type" and "windows share type", hence the need for possible intervention at the CLI. It wasn't clear from your first post if you had made changes to the top level of your pool, e.g. at /mnt/mypool/ - that really should be left as "unix type" and with owner/group set to "root/wheel". In FN11.3 the user is prevented from making changes at the top level.

I don't know if it's relevant here, but the default ACL on new ‘Windows’ datasets was changed: https://www.ixsystems.com/blog/library/freenas-11-2-u7/

 

[rudds]

I don't know about existing datasets, but IIRC in FreeNAS 11.2-U7 if a newly created dataset that is initially "unix share type" is then shared via SMB with the "default permissions" option set, the dataset then becomes a "windows share type" with its "aclmode" property set to "restricted". That should be easy enough to check/test.

Ha, great minds -- I came back to say that I've discovered exactly this. Creating a new SMB share for a given dataset with default permissions enabled is what's reverting that dataset back to the Windows share type in the web UI. However, the aclmode property on those datasets remains at passthrough even after the change. Worth noting, I've been running this config for almost two years and never saw this behavior before now, so it seems like whatever FreeNAS considers the "default permissions" for the purpose of creating a share on those datasets has changed to Windows? I'm not sure where a setting like that might live.

It's kind of academic anyway, because even creating an SMB share with default permissions disabled is still producing a share that Windows won't let me access due to a vague permissions error (though it does result in the given dataset remaining set to the Unix share type). This is happening across all my pools now, the main RAIDZ1 and lone SSD and even a USB hard drive I plugged in for extra testing, so it seems like the problem is occurring at the FreeNAS level rather than something wrong with the actual pools.

I seem to remember FreeNAS 11.2-U7 GUI does not handle switching a dataset back and forth between "unix share type" and "windows share type", hence the need for possible intervention at the CLI.

The web UI at least makes it seem like it does handle the conversion -- all the options are there, and if you apply permissions recursively it thrashes for a good minute, as if it's walking all the directories and making the changes. But I've also done the manual setfacl/chown/chmod as mentioned and it didn't seem to help.

It wasn't clear from your first post if you had made changes to the top level of your pool, e.g. at /mnt/mypool/ - that really should be left as "unix type" and with owner/group set to "root/wheel". In FN11.3 the user is prevented from making changes at the top level.

I'm only modifying the child datasets underneath the storage pool's top-level dataset -- haven't ever touched any ownership or permissions there -- so that shouldn't be a problem.

 

[KrisBee]

Going from "unix type" to "windows type" dataset might look OK via the GUI, but what is going on under the hood? Is the aclmode property even re-set correctly? I don't know if you've been using a non-standrad config in the past for your shares, but don't you want to stick to windows type share for access from wIndows clients? Can't comment on the knock-on effect re: your jails etc.

 

[rudds]

Jails are part of the reason I want to stick with Unix-style permissions since I'm running a number of media-oriented services in jails that need access to various parts of my storage pool.

My config since I started using FreeNAS has simply been to use the Unix share type for all datasets (except that one SSD I set to Windows erroneously) and point SMB shares at those datasets for access from Windows. Not sure if that's considered non-standard, but other than requiring me to manage all permissions on the FreeNAS side (which is what I prefer) it's worked just fine till now.

Regardless of my preferences, this issue with datasets reverting to other share types surely can't be intended behavior, can it? It's basically left my NAS all but inoperable for all of my everyday use cases.

 

[KrisBee]

I understand why you settled on the scheme that worked for you, but FreeNAS worked against you as the "deault permission" checkbox doesn't even show until you hit "ADVANCED MODE" when creating a windows share in the new UI.

RE: your last question. I believe the answer is yes if the "default permission" is checked in the windows share config.

 

[rudds]

I really think something else is at work here since I've made numerous SMB shares pointing at these Unix-type datasets over time with no problems. The trouble only started after I converted that one dataset from Windows to Unix, which seems to have triggered a deeper problem than just mismatching share permissions and protocols.

The worst issue is that even if I leave the share type set to Windows, I can't actually access any of the shares from Windows even with the right credentials ("You do not have permission to access <sharename>" is as specific as it gets). My jails also still can't access their mount points regardless of what the ownership and permissions are on the underlying datasets. There's something deeply wrong with permissions across the whole machine now and I honestly don't know what to try next.