SCALE Beta ACL and Permissions Errors

[SpinMop]

Hi Everyone,

I deployed SCALE beta earlier this morning but I cannot seem to get the ACL permissions, owner or group of my storage devices changes or updated. I run into errors such as

Error: local variable 'aclstring' referenced before assignment

when trying to update the owner to a new user and the group to 'users'

or

Error: [EINVAL] filesystem.setacl.path: The specified path is a ZFS pool mountpoint "(/mnt/<redacted>)" [EINVAL] filesystem.setacl.dacl: Named (user or group) POSIX ACL entries require a mask entry to be present in the ACL. [EINVAL] filesystem.setacl.dacl: Presence of [USER_OBJ] entry is required. [EINVAL] filesystem.setacl.dacl: Presence of [GROUP_OBJ] entry is required. [EINVAL] filesystem.setacl.dacl: Presence of [OTHER] entry is required.

When I try to add the local user using the ACL manager.

Is this a bug in the beta? Are these just not being set up properly? I've been trying for hours to figure out what's wrong.

 

[oumpa31]

I got the same thing when I started testing it on my test bench

 

[SpinMop]

I got the same thing when I started testing it on my test bench

Yes I saw your thread and commented as well. It's unfortunate that this is still throwing up errors.

 

[littleNewton]

I got this problem too.

I don't know very well about ACL settings.

 

[morganL]

@SpinMop Can you confirm that the issue doesn't exist for new datasets and shares... just for changing existing datasets and shares.

 

[littleNewton]

This bad thing happens only when I set like the following:

1. Click the credential button to create a new User
2. Click the storage button and select a pool to set the permission
3. choose set ACL
4. just add a new ACL item: User, the new user, Read/Write/Execute
5. Save.

error occured...

I don't know why.

 

[HeyRay2]

I just fought with this on my new SCALE install over the last few days, and finally got it "mostly" figured out.

The following ACL entries are required for each dataset you want to set ACL permissions on:

• A "User Obj" entry, which sets the permissions for the "User" who owns the dataset
• A "Group Obj" entry, which sets the permission for the "Group" who owns the dataset
• A "Other" entry, which sets permissions for any user or group who does not have ownership or specific ACL permissions to the dataset

If you want to add ACL permissions for more users and groups beyond this, you have to add a "Mask" entry, which set the "maximum" permissions that are allowed for any user or group that has access to the dataset (see https://docs.oracle.com/cd/E19455-0...~:text=The ACL mask.,all the users and groups. for more details).

 

[anodos]

There's a webui rewrite in progress for the POSIX1E and NFSv4 ACL editor. POSIX1E ACLs require User (USER_OBJ), Group (GROUP_OBJ), Other entries. A MASK entry is required if any additional named USER and GROUP entries are added. This is an implementation / design constraint of how POSIX ACLs work. POSIX1E ACL implementation actually uses two xattrs (ACCESS and DEFAULT). The ACCESS ACL determines permissions for the current file. Directories optionally have a DEFAULT that defines permissions as they will be inherited in the ACCESS ACL of newly created files or directories.

Default entries define what will be inherited / apply to files when the ACL is applied recursively, and same rules apply to them. If you want an ACL experience more consistent with Windows and TrueNAS Core, then you can switch the ZFS dataset acltype from POSIX to NFSv4.

 

[SantiCF]

There's a webui rewrite in progress for the POSIX1E and NFSv4 ACL editor. POSIX1E ACLs require User (USER_OBJ), Group (GROUP_OBJ), Other entries. A MASK entry is required if any additional named USER and GROUP entries are added. This is an implementation / design constraint of how POSIX ACLs work. POSIX1E ACL implementation actually uses two xattrs (ACCESS and DEFAULT). The ACCESS ACL determines permissions for the current file. Directories optionally have a DEFAULT that defines permissions as they will be inherited in the ACCESS ACL of newly created files or directories.

Default entries define what will be inherited / apply to files when the ACL is applied recursively, and same rules apply to them. If you want an ACL experience more consistent with Windows and TrueNAS Core, then you can switch the ZFS dataset acltype from POSIX to NFSv4.

hi @anodos !

is this a fix that will come through autoupdate? is something we can fix ourselves?


thanks

 

[morganL]

hi @anodos !

is this a fix that will come through autoupdate? is something we can fix ourselves?


thanks

This will be in SCALE 21.08 and prior to that in the nightlies. We'll let everyone know when the eagle lands.

 

[anodos]

hi @anodos !

is this a fix that will come through autoupdate? is something we can fix ourselves?


thanks

The ACL API works. You just need to make sure that all of the required items are present in the payload. This means a minimum of 6 entries USER_OBJ, GROUP_OBJ, OTHER with and without "default" checked. If you add named entries (GROUP, USER), then you need to add a MASK entry as well.

 

[SantiCF]

thank you so much for the replies @morganL and @anodos

 

[Ryan Haver]

The ACL API works. You just need to make sure that all of the required items are present in the payload. This means a minimum of 6 entries USER_OBJ, GROUP_OBJ, OTHER with and without "default" checked. If you add named entries (GROUP, USER), then you need to add a MASK entry as well.

@anodos

I am running beta 21.06 and migrated from the latest version of TrueNAS CORE. I'm getting errors when trying to add a named entry to existing ACLs on all shares even after supplying USER_OBJ, GROUP_OBJ, OTHER with and without "default" checked, and a MASK entry.

Error: [EINVAL] filesystem.setacl.dacl: Presence of default [USER_OBJ] entry is required. [EINVAL] filesystem.setacl.dacl: Presence of default [GROUP_OBJ] entry is required.

It appears to require USER_OBJ and GROUP_OBJ entries with and without default checked, but even after adding those when attempting to save the ACLs I am presented with the Operation not supported error seen below.

Error: [EFAULT] Failed to set ACL [user::rwx,group::rwx,other::---,default:other::---,mask::---,default:user::---,default:group::---,user:1001:rwx] on path [/mnt/data-pool/media]: setfacl: /mnt/data-pool/media: Operation not supported

It doesn't seem to care what permissions are set for any of the entries, as it will fail with the same [EFAULT] error message every time.

 

[blanka]

I have exact the same issue as Ryan Haver. I also got the Operation not supported issue when I tried to set ACL. Please help to check and let us know if there is any workaround or any update that will fix this issue. Thanks!

 

[anodos]

@anodos

I am running beta 21.06 and migrated from the latest version of TrueNAS CORE. I'm getting errors when trying to add a named entry to existing ACLs on all shares even after supplying USER_OBJ, GROUP_OBJ, OTHER with and without "default" checked, and a MASK entry.

Error: [EINVAL] filesystem.setacl.dacl: Presence of default [USER_OBJ] entry is required. [EINVAL] filesystem.setacl.dacl: Presence of default [GROUP_OBJ] entry is required.

It appears to require USER_OBJ and GROUP_OBJ entries with and without default checked, but even after adding those when attempting to save the ACLs I am presented with the Operation not supported error seen below.

Error: [EFAULT] Failed to set ACL [user::rwx,group::rwx,other::---,default:other::---,mask::---,default:user::---,default:group::---,user:1001:rwx] on path [/mnt/data-pool/media]: setfacl: /mnt/data-pool/media: Operation not supported

It doesn't seem to care what permissions are set for any of the entries, as it will fail with the same [EFAULT] error message every time.

Check if acltype is set to "None" or "Off" this was an issue for some pools imported from Core. We've addressed in nightlies.

 

[blanka]

Check if acltype is set to "None" or "Off" this was an issue for some pools imported from Core. We've addressed in nightlies.

After setting to POSIX, I can set the ACL. However, I still can't use the "option for "Apply permissions recursively". It ask to set default but when I set default, other error will generate. Any idea what I need to do next? Thanks!

 

[Ryan Haver]

Check if acltype is set to "None" or "Off" this was an issue for some pools imported from Core. We've addressed in nightlies.

After setting POSIX I'm able to adjust ACLs, but they seem to do nothing. Applying them recursively removes the Named entry and the MASK entry completely.

I thought this may be an issue with the way I originally set up the SMB shares, but after removing one of the shares I cannot strip the ACLs to recreated the SMB Share due to the below error. I never remember setting these shares up for NFS, but it's possible at one point they were.

I've attempted the following, but still get the below error when the ACL type is set to POSIX

1. Changed the ACL type to NFS
2. Stripped the ACLs
3. Changed the ACL type back to POSIX
4. Attempted to strip ACLs again, but got the same error message seen below

Error: [EINVAL] filesystem.setacl.acltype: ACL type mismatch. On-disk format is [POSIX1E], but received [NFS4].

 

[morganL]

Windows-style (NFSv4) ACLs have not been possible in ZFS on Linux until now. Only the POSIX permissions were possible.

Its taken quite a bit of new software to make windows-style ACLs possible. SCALE 21.06 has the base capability, no ACL Editor and very little test time.

The Windows-style ACL Editor is in SCALE 21.08 and will make it easier to resolve some of these issues. the Nightly has the functionality, but has not been through a full QA cycle. Feel free to test the Nightly, but the 21.08 release will be better. After that we can resolve any remaining issues.

 

[anodos]

After setting POSIX I'm able to adjust ACLs, but they seem to do nothing. Applying them recursively removes the Named entry and the MASK entry completely.

I thought this may be an issue with the way I originally set up the SMB shares, but after removing one of the shares I cannot strip the ACLs to recreated the SMB Share due to the below error. I never remember setting these shares up for NFS, but it's possible at one point they were.

I've attempted the following, but still get the below error when the ACL type is set to POSIX

1. Changed the ACL type to NFS
2. Stripped the ACLs
3. Changed the ACL type back to POSIX
4. Attempted to strip ACLs again, but got the same error message seen below

Error: [EINVAL] filesystem.setacl.acltype: ACL type mismatch. On-disk format is [POSIX1E], but received [NFS4].

Sounds like an incorrect payload is being submitted by the webui. Is this on BETA or nightlies?

 

[blanka]

Windows-style (NFSv4) ACLs have not been possible in ZFS on Linux until now. Only the POSIX permissions were possible.

Its taken quite a bit of new software to make windows-style ACLs possible. SCALE 21.06 has the base capability, no ACL Editor and very little test time.

The Windows-style ACL Editor is in SCALE 21.08 and will make it easier to resolve some of these issues. the Nightly has the functionality, but has not been through a full QA cycle. Feel free to test the Nightly, but the 21.08 release will be better. After that we can resolve any remaining issues.

It's 1.5 months on 21.06 now. Any plan or schedule when will 21.08 release? With the ACL limitation, I can't use TrueNAS Scale at all. I am a long time TrueNAS Core user and I found out TrueNAS Scale is much more suitable for my loading!!