[zfsacl] is not a permitted VFS object on SCALE. (Migration Core to Scale)

[majerus]

Just did this migration, looks like permissions for SMB shares are not handled well at all. Trying to figure out what is the right way to proceed. It looks like some of my shares have 'vfs objects = zfs_space zfsacl streams_xattr' defined as extra parameters. I have been running truenas / freenas on this array since 2015. Should I just removed these 'advanced options' and save the shares? Any concern in doing this, really dont want to put my data at risk.

An ACL is detected on the selected path but Enable ACL is not selected for this share. ACLs must be stripped from the dataset prior to creating an SMB share.

[EINVAL] sharingsmb_update.auxsmbconf.sharingsmb_update.auxsmbconf.auxsmbconf: [zfs_space] is not a permitted VFS object on SCALE. [EINVAL] sharingsmb_update.auxsmbconf.sharingsmb_update.auxsmbconf.auxsmbconf: [zfsacl] is not a permitted VFS object on SCALE. [EINVAL] sharingsmb_update.acl: ACL detected on /mnt/DeepEnd/Client_Shares/Vault. ACLs must be stripped prior to creation of SMB share.

Attempting to enable "ACL"



[zfsacl] is not a permitted VFS object on SCALE.

​

 

[Brian Stretch]

Same here. Deleting zfsacl caused it to complain about zfs_space and at that point I just deleted the whole auxiliary line and my share reappeared in Windows. No idea whether that was a smart move.

 

[majerus]

Yea same, i wish someone that knew this from a technical perspective would answer :)

 

[anodos]

We don't migrate auxiliary parameters. Generally, speaking once you put raw text into a field, you're on your own. zfsacl and zfs_space are FreeBSD-specific modules.

 

[Brian Stretch]

Could obsolete auxiliary parameters be removed automatically during Core to Scale upgrades? This was really confusing. These were parameters that FreeNAS added way back when, not parameters that were added manually.

 

[anodos]

Could obsolete auxiliary parameters be removed automatically during Core to Scale upgrades? This was really confusing. These were parameters that FreeNAS added way back when, not parameters that were added manually.

No. I'd rather that we avoid too much parsing in auxiliary parameters because altering them can affect security of share or how data is written. I will file a ticket to add to our "known impacts" of Core -> SCALE migration, but onus will be on the administrator to manage any auxiliary parameters.

 

[majerus]

To be honest here I dont think I manually added any of these, and pretty much have zero idea of what they mean honestly. I can google them but at the end of the day truenas or freenas added them to the shares when it was created at some point.. Feels like some lay person explanation as to what they are could be nice.

 

[planedrop]

To be honest here I dont think I manually added any of these, and pretty much have zero idea of what they mean honestly. I can google them but at the end of the day truenas or freenas added them to the shares when it was created at some point.. Feels like some lay person explanation as to what they are could be nice.

Just wanted to chime in here and say that I came across the same thing on my Scale migration, I 100% never ever added these parameters into the system, but stripping them out also didn't damage anything and so far all my data is in tact and seems fine.

I did notice something interesting though, it was only my 2 oldest shares from like 5 years ago (whatever FreeNAS version was at the time) that had these parameters set, newer SMB shares didn't have anything in them and are working as I would expect.

The only other difference between these shares is that the 2 which had these set were accessed from Win11 machines relatively recently, and all the others have only been accessed by either Win10 or Server machines (and Linux servers).

 

[planedrop]

No. I'd rather that we avoid too much parsing in auxiliary parameters because altering them can affect security of share or how data is written. I will file a ticket to add to our "known impacts" of Core -> SCALE migration, but onus will be on the administrator to manage any auxiliary parameters.

FYI I don't think this was ever put into the documentation about this and I think it still should.

Putting the "onus" on the administrator, when these parameters were never set by the administrator, isn't the solution to this issue.

Of course this is why I did it on a test system first to be sure things are fine before doing anything critical, but it's still not a good look.

On the other hand I'm glad you even can easily upgrade from Core to Scale, and considering this is the only issue (so far) it was remarkably smooth.

 

[anodos]

Add ACL wrapper libraries by anodos325 · Pull Request #92 · truenas/samba

Contribute to truenas/samba development by creating an account on GitHub.

github.com

I have WIP to wrap around these libraries and VFS modules. This makes it so that zfsacl.so is compiled on Linux via providing a libsunacl wrapper library (solaris acl / facl syscalls). Functionality will be same as on FreeBSD side, hopefully will make it in time for 22.02.2, but as you can see from PR it's a rather large undertaking.

 

[anodos]

Basically the ongoing work is to create a common ACL library for Linux / FreeBSD (lib/zfsacl) which provides full NFSv41 API, create bindings for it (pyzfsacl.c), and also create a solaris ACL wrapper lib/sunacl which is used in vfs_zfsacl to implement legacy ACL support on both platforms (for old FreeNAS servers).