Cannot set ACL permission on Imported Pool

[Carlton_R]

I've imported pools, using the FreeNAS GUI tool, into the lasted version of FreeNAS (11.3-U4) from a previous version v9.3. I imported two pools (both Windows shares) one has done so with no issues, but the other one is refusing to accept any applied ACLs.

When I try and save the setting under Edit ACL it returns the following error massage:

Error: [EINVAL] At least one inheritable ACL entry is required

I've tried all sorts of things to correct it, but to no avail. I would therefore be grateful for any assistance in resolving this issue.

Many thanks

 

[anodos]

Please look carefully at ACL editor and make sure that at least one entry has FLAGS set to BASIC: INHERIT.

 

[Carlton_R]

Thank you very much for this . . . it fixed the issue.

Unfortunately, I have a secondary, related issue, in that now that the ACL issue is resolved I'm unable to 'Edit Permissions', the following massage is displayed when I attempt to do so:

Dataset Has Complex ACLs
This dataset has an active ACL. Changes to permissions must be made with the ACL editor. Open ACL editor?

Many thanks

As an aside I can map to the share using a Windows box, and able to read and write folders and files, but unable to move/delete.

 

[Carlton_R]

Update: I have setup the relevant permissions using the ACL editor [full control], and now have the ability to create and delete files and folders at the top level of the share, but when accessing thefolders I have no rights what so whatsoever, other then just read/view.

I have tried selecting ‘Apply permissions recursively’ but to no avail.

 

[KrisBee]

@Carlton_R Have you updated to FreeNAS 11.3-U4.1 ? There was a regression in the ACL editor, now fixed and ‘Apply permissions recursively’ works.

 

[Carlton_R]

As suggested have updated to FreeNAS 11.3-U4.1 . . . but unfortunately the issue still remains. As mentioned, I can create and delete files and folders at the top level of the share, but cannot create anything within any these folders.

Comparing the two imported pools 'shares', using a Windows box to connect to the shares, the following Windows Security permissions have been applied:

- Both of the shares top level have Everyone, root (Unix User\root) and the username (Unix User\root).

- Working share folder: have these cascaded, with all three present.

- Not working share folder: Only has the Everyone group for both the original folders and for any new folders created. There is a change in that prior to reapplying the permission, after the FreeNAS udate, these folders, used to contained the previous imported user and group GID, which has now gone.

The odd thing is, is that I can manage the 'Working share' using the Edit Permissions (with the ACL flags set to No Inherit), in contrast to the 'not working share'. There is a change in that prior to reapplying the permissions, after the FreeNAS update, these folders used to contain the previous user and group GID which were imported, these have now gone.

 

[Carlton_R]

Update: When creating files at top level of the share within the 'not working share’ they inherit the correct permissions, which you would expect, it's only the folders which do not.

 

[KrisBee]

I would have thought that if your compare side by side what you see in the WebUI ACL edit screen for your two share paths, the differencs in ACL/ACE would become clear. Otherwise, in the FreeNAS shell use the getfacl command on the share path and post the output.

For example:

Code:

root@freenas[~]# getfacl /mnt/NasPool/test
# file: /mnt/NasPool/test
# owner: root
# group: wheel
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow
root@freenas[~]#

For completeness, it's also worth posting the output of the shell command testparm -s

 

[Carlton_R]

All sorted, my fault . . . down to my lack of understanding of ACL's, and probably is still the case, much more research is required me thinks.

I changed the three default entries to Inherit, so owner@, Group@ and the third to the users Group. Applied permissions recursively, and everything did as it was supposed to do. One thing that I am at a loss to understand is why one Pool can be configured using 'Edit Permissions' whilst the other refuses, and only allows it to edited with 'Edit ACL' !.

Thank you very much for everyone's assistance, very much appreciated . . . I think I'm on a very steep learning curve.

 

[anodos]

All sorted, my fault . . . down to my lack of understanding of ACL's, and probably is still the case, much more research is required me thinks.

I changed the three default entries to Inherit, so owner@, Group@ and the third to the users Group. Applied permissions recursively, and everything did as it was supposed to do. One thing that I am at a loss to understand is why one Pool can be configured using 'Edit Permissions' whilst the other refuses, and only allows it to edited with 'Edit ACL' !.

Thank you very much for everyone's assistance, very much appreciated . . . I think I'm on a very steep learning curve.

"Edit Permissions" is only available if a path lacks ACLs. The reason for this is that permissions can only be represented in a lossless way as a POSIX mode if extended ACLs are _not_ present. So the gui makes a middleware call to `filesystem.acl_is_trivial` to determine whether the to allow editing via "permissions".

 

[KrisBee]

Things can get in a tangle when dealing with datasets created in earlier versions. Old version used to distinguish between unix, mac and windows share types. It's now just generic or smb when creating new datasets. Additionally, the WebUI no longer allows the top level of a pool to be shared or its ACL changed. Your "pool" that allows "edit permissions" can't have the default ACL that FreeNAS now sets for any dataset intended to be used for a windows share, most likely it was originally created as a unix share type. As @anodos says, it can't have any extended ACL which are indicated by the presence of a + symbol when using "ls" to list files/dir in the shell.

I think it would be worth you getting your datasets/shares in a consistent state. Ask for help if you need it.