SOLVED Corral to 11 leads to permissions and share type inconsistencies

[Scentle5S]

Hello everyone,

After the recent events regarding Corral, I was seriously considering to upgrade to 11. I wanted to wait for 11.1 and the implementation of Docker, but some other problems with my containers under Corral made me switch.

The upgrade went fine and my pool was successfully imported.

However, I noticed that most of my datasets have the UNIX share type and Unix permissions in the GUI. Now there are three things wrong with that :

1. I'm sure I set everything as ACL under Corral since my shares were SMB shares
2. I was using Windows to manage my permissions
3. When I list the contents of my datasets, I get something like this :

Code:

drwxrwx---+ 12 1000  1000   13 Sep 13 22:51 PrivateDataset1
drwxrwx---+ 15 1000  1000   36 Oct  5 00:32 PrivateDataset2
drwxrwx---+  8 1000  1000   10 Oct  4 23:02 PrivateDataset3
drwxrwx---+  7 1000  1000   11 Oct  4 23:56 PrivateDataset4
drwxrwxr-x+ 11 1000  1000   14 Oct  5 00:36 PublicDataset
drwxr-xr-x   8 root  wheel   8 Oct  6 17:57 jails
drwxrwxr-x+  7 plex  plex	7 Oct  6 17:13 Plex
drwxr-x---   3 1000  1000	3 Oct  6 17:13 Users

As you can see, all the datasets that were meant to be shared with various machines (macOS and Windows based) all have a "+" sign after the permissions, indicating that the permissions are Windows based.

Based on these elements, I have many questions :

1. Is there indeed an inconsistency between what the GUI shows me and what's actually going on under the hood ? If so, why is that ?
2. Can I "change" the share type and permissions type of my datasets back to Windows without risking to damage my data ? Assuming that this might be a bug in the GUI I should be fine since nothing should change anyway, but I don't want to risk it. Also I read that these settings are best set initially and should not be changed later, so...
3. Is there a valid reason for doing this (number 2. I mean) ? I read that in order to use SMB shares it is best to use Windows share types and permissions. But I also read another user saying that this caused him problems, so he used Unix share types and permissions. In the end I still don't know "what's best" and what the differences are, besides one using Unix permissions that can be managed with chmod and the other using ACLs that can be managed with a Windows machine.
4. I also still don't fully understand why there are separate sections for "Share type" and "Permission type". To me they are basically the same. Plus when you create a new dataset, the share type defines the permission type.

Right now I'm leaving everything as it is, since I don't want to put my data at risk.

Thanks in advance

Scentle5S

Edit : The more I think about this, the more I suspect a bug with the GUI, which probably shows the "last value" entered in those fields, which might be nothing in my case since the pool and the datasets were created in Corral. So I suppose all I'm seeing are the default values, just like I see root as the owner and wheel as the group, when I clearly set those to my user account under Corral. This is also confirmed by the 1000 value for UID and GID in the listing before. I'm going to try a simple share on a "not-so-important" dataset and see what's what.

 

[Ericloewe]

Maybe you should've done some reading first:
https://forums.freenas.org/index.ph...ng-from-freenas-corral-to-freenas-9-10-11.36/

Corral is unique enough to cause weird problems that need to be addressed at the root.

While you're at it, do me a favor and run zfs list -H -o name,aclmode | awk '/discard_chmod/ { print $1 }'. I'm interested in seeing what zfs list says about the unknown aclmode...

 

[Scentle5S]

Thanks for your answer.

I did read this FAQ before upgrading (should have mentioned it, sorry) and I didn't see any reason not to do it. If there was any, then I didn't get it, although everything in the FAQ seemed clear to me.

The command doesn't output anything, so I figured my pool wasn't affected by the discard_chmod issue, right ?

 

[Ericloewe]

The command doesn't output anything, so I figured my pool wasn't affected by the discard_chmod issue, right ?

No, since it only works properly on Corral. I forgot to mention that the output I'd like to see is without the awk part:
zfs list -H -o name,aclmode
Feel free to censor out any dataset names that might leak information.


In any case, the solution to your problem is to set the aclmode to restricted on all datasets shared with SMB, as per the resource.

I also still don't fully understand why there are separate sections for "Share type" and "Permission type". To me they are basically the same. Plus when you create a new dataset, the share type defines the permission type.

The permissions type selects the aclmode, share type sets case sensitivity and similar settings. You're right to say that they should probably be unified, at least by default.

I read that in order to use SMB shares it is best to use Windows share types and permissions. But I also read another user saying that this caused him problems, so he used Unix share types and permissions.

It's not just best, it's required. You can use Unix permissions, but it's unsupported and may break things. Samba is enough of a pain without self-inflicted wounds...

As for your UID/GID not being picked up by the GUI, it may simply be a matter of the command failing because it doesn't know what to make of the aclmode. Fix that first and then check again.

 

[Scentle5S]

In any case, the solution to your problem is to set the aclmode to restricted on all datasets shared with SMB, as per the resource.

Actually, in the meantime I was able to access my shares : my new user had the UID 1001 instead of 1000 and same for the group, I didn't notice at first. So I recreated both and now I can access my shares.

As for your UID/GID not being picked up by the GUI, it may simply be a matter of the command failing because it doesn't know what to make of the aclmode. Fix that first and then check again.

All my datasets still show Unix share type and permissions in the GUI. So the fix for this is to set the aclmode to restricted ? Sorry if I make you repeat, I would just like to be sure.

Here is the output of the command :

Code:

Storage passthrough
Storage/.system passthrough
Storage/.system/configs-76c11d7f8a944b3d8e42fe35420dbaa3		passthrough
Storage/.system/cores   passthrough
Storage/.system/rrd-76c11d7f8a944b3d8e42fe35420dbaa3	passthrough
Storage/.system/samba4  passthrough
Storage/.system/syslog-76c11d7f8a944b3d8e42fe35420dbaa3 passthrough
Storage/.vm_cache	   passthrough
Storage/.vm_cache/boot2docker   passthrough
Storage/.vm_cache/boot2docker/initrd	passthrough
Storage/.vm_cache/boot2docker/vmlinuz64 passthrough
Storage/.vm_cache/ubuntu-14.04-9p	   passthrough
Storage/.vm_cache/ubuntu-14.04-9p/rootfs		passthrough
Storage/.vm_cache/ubuntu-14.04-9p/rootfs/rootfs passthrough
Storage/.vm_cache/ubuntu-server-16.04-vnc	   passthrough
Storage/.vm_cache/ubuntu-server-16.04-vnc/os	passthrough
Storage/.vm_cache/ubuntu-server-16.04-vnc/os/os -
Storage/SomeDataset	 -
Storage/SomeDataset	 passthrough
Storage/SomeDataset  -
Storage/SomeDataset	   -
Storage/SomeDataset   -
Storage/SomeDataset	-
Storage/SomeDataset/SomeSubDataset	   passthrough
Storage/SomeDataset/SomeSubDataset	passthrough
Storage/SomeDataset/SomeSubDataset	 passthrough
Storage/SomeDataset/SomeSubDataset	  passthrough
Storage/SomeDataset -
Storage/SomeDataset	passthrough
Storage/SomeDataset	restricted
Storage/SomeDataset/SomeSubDataset  -
Storage/SomeDataset/SomeSubDataset	-
Storage/SomeDataset   passthrough
Storage/SomeDataset/SomeSubDataset   passthrough
Storage/SomeDataset  -
Storage/jails   passthrough
Storage/jails/.warden-template-standard passthrough
Storage/jails/SomeJail	  passthrough
Storage/jails/SomeJail		passthrough
Storage/vm	  passthrough
Storage/vm/Scentle5S	passthrough
Storage/vm/Scentle5S/docker	 passthrough
Storage/vm/Scentle5S/files	  passthrough
Storage/vm/Ubuntu	   passthrough
Storage/vm/Ubuntu Server		passthrough
Storage/vm/Ubuntu Server/os	 -
Storage/vm/Ubuntu/files passthrough
Storage/vm/Ubuntu/rootfs		passthrough
freenas-boot	discard
freenas-boot/ROOT	   discard
freenas-boot/ROOT/Initial-Install	   discard
freenas-boot/ROOT/default	   discard
freenas-boot/grub	 

So the command you gave me should still show discard_chmod if there is a problem here, right ? It's just a different command to run than under Corral ? I think I ran the older command ( zfs set aclmode=oops dataset) for my datasets when I was under Corral and I didn't see any discard_chmod.

 

[Ericloewe]

So the command you gave me should still show discard_chmod if there is a problem here, right ?

No, only on Corral.

So the fix for this is to set the aclmode to restricted ?

The ones shared with SMB should be restricted. Other datasets will depend on what they're used for.

Actually, in the meantime I was able to access my shares : my new user had the UID 1001 instead of 1000 and same for the group, I didn't notice at first. So I recreated both and now I can access my shares.

Okay, that's one less mystery.

 

[Scentle5S]

The ones shared with SMB should be restricted.

Okay, I've changed them and they now show as restricted.

However, they still show as Unix share type and permission in the GUI. Is there an additional step to fix this ?

Other datasets will depend on what they're used for.

I only changed the aclmode on the shared datasets, like you said. But should I change it for others as well ? Basically, when I create a Windows dataset, it gets the restricted aclmode, and all my datasets were initially created that way, some of them are just not shared anymore and are used as storage for jails, that's the only difference with the shared ones. So is there a valide reason for them to show as " - " and "passthrough" now or is it just Corral's fault and I should set them back to restricted ?

 

[Ericloewe]

No, you definitely don't want to set everything to restricted, as that will break many things.

However, they still show as Unix share type and permission in the GUI. Is there an additional step to fix this ?

Try a reboot. If that doesn't fix it, export and import the pool. If that doesn't work, we've got a bug.

 

[Scentle5S]

No, you definitely don't want to set everything to restricted, as that will break many things.

Could you be a little more specific please ? Don't get me wrong : I fully trust you and I really appreciate your help, but I'm curious in general and I enjoy understanding a bit more how things work, beyond the "don't do that or it will break" approach.

Therefore, if that doesn't require being an total expert in ZFS, and doesn't force you to write a 100 lines answer, I'd appreciate to understand things like :

1. What would break if I do this ?
2. What in FreeNAS can change a Windows dataset's aclmode from restricted to something else and why ? This is related to 1..
3. When I see a dataset with the aclmode " - ", does that mean it's a residue from Corral or is there a "blank" value for aclmodes ?
4. Basically, what are the differences between the different aclmodes ? I found this link but that's a bit too theoretical for me, plus there's no mention of the restricted aclmode. Real world examples, possibly related to FreeNAS would help.

In the end, I'd like to be able to "fix" my datasets if something isn't set the way it should be. Because even though everything seems to be working now (can access my data and shares, my jails with storage are working, and so on), I don't like having potential hidden residues of Corral that I don't understand in here, as this might cause issues in the future. I want everything to be the way it would have been if I went with FreeNAS 11 in the first place.

Anyway, if you don't have time or don't want to explain a bit more I understand. That's something that may require me diving deeper in the world of permissions.

Try a reboot. If that doesn't fix it, export and import the pool. If that doesn't work, we've got a bug.

A reboot is the first thing I tried. I detached the pool (if that's what you mean by "export") and reattached it but no difference : the command still shows the datasets as restricted but they also still show up as Unix in the GUI :

Code:

Scentle5S@freenas:~ % zfs list -H -o name,aclmode | grep Media
Storage/Media   restricted

 

[Ericloewe]

What would break if I do this ?

Literally everything that uses chmod (mostly stuff in jails, given it's the data pool).

What in FreeNAS can change a Windows dataset's aclmode from restricted to something else and why ? This is related to 1..

The permission type setting.

When I see a dataset with the aclmode " - ", does that mean it's a residue from Corral or is there a "blank" value for aclmodes ?

I don't think blank values are possible. I don't know what is going on there, but it may be ZFS not recognizing discard_chmod.

Basically, what are the differences between the different aclmodes ? I found this link but that's a bit too theoretical for me, plus there's no mention of the restricted aclmode. Real world examples, possibly related to FreeNAS would help.

Permissions beyond RWX for Owner/Group/Everyone in Unixland are... complicated. ZFS supports NFSv4 ACLs to allow for that sort of thing, but different applications have different requirements for how to handle them. They can be ignored, for instance. One specific problem is that chmod will clobber the ACLs, ruining them. So, aclmode=restricted is used and it disallows chmod, protecting the ACLs from semi-accidental chmods.

The openZFS documentation will have the details for the various aclmodes.

A reboot is the first thing I tried. I detached the pool (if that's what you mean by "export") and reattached it but no difference : the command still shows the datasets as restricted but they also still show up as Unix in the GUI :

Bah, just move the radio button to Windows and save that. It should be safe to your permissions.

 

[Scentle5S]

Literally everything that uses chmod (mostly stuff in jails, given it's the data pool).

I'm not sure if you talk about the default jails dataset or about the datasets used as storage for the jails. I decided to create a test jail with a test dataset for storage, with Windows permissions, to see what happens with everything freshly created.
The jail didn't change anything to the dataset which still has the default required aclmode, and everything worked fine.
So I ended up resetting the aclmode to restricted for my real jail storage dataset and everything went fine.

I don't think blank values are possible. I don't know what is going on there, but it may be ZFS not recognizing discard_chmod.

I also reset the aclmode for the remaining "personal" datasets, starting with one that wasn't so important and for which I had external backup, everything went fine here as well.

Bah, just move the radio button to Windows and save that. It should be safe to your permissions.

Again, I started with a not so important dataset, no problem, so I went on with the others. They all show up as Windows share type and permissions again in the GUI.

In the end, all my personal datasets have the restricted aclmode back. The only ones I left as passthrough are the ones used as home folders for users and the default jails dataset.

Thank you for all the explanations, I understand things a bit more now.

I know this could be the subject of a new thread, but since it's linked to the update process as well I'll try here :
There are two hidden folders / datasets in my pool : .system and .vm_cache, I'm pretty sure that the latter is a residue from Corral since it mentions boot2docker, and I suppose that .system is used by FreeNAS 11 here, since it doesn't show up when I list the content of the pool, whereas .vm_cache does.
The question is : can I safely remove at least .vm_cache and, if so, how ? Since they are hidden, I don't know if they are folders or datasets and I can't do anything through the GUI).

 

[Ericloewe]

The .system dataset is used by 9.x/11.x, so definitely don't nuke it. No idea what exactly .vm_cache does.

Since they are hidden, I don't know if they are folders or datasets and I can't do anything through the GUI).

Well, you can tell if they're datasets using zfs list. Use zfs destroy to delete datasets (use caution, it's irreversible, even if you keep snapshots). Check the man page for details.

 

[Scentle5S]

Perfect, it's done.

I'm marking the thread as solved.

Again, thank you very much for your help !