Error einval at least one inheritable acl entry is required

• This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
  By continuing to use this site, you are consenting to our use of cookies.

SCALE Beta ACL and Permissions Errors

SpinMop

Cadet

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’

Error: [EINVAL] filesystem.setacl.path: The specified path is a ZFS pool mountpoint «(/mnt/ )» [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

Patron

SpinMop

Cadet

littleNewton

Cadet

I got this problem too.

I don’t know very well about ACL settings.

morganL

Captain Morgan

littleNewton

Cadet

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.

I don’t know why.

HeyRay2

Cadet

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.

Main NAS
======
TrueNAS-12.0-U4
Core i3-4170
ASRock H97 Pro4 MoBo
32GB DDR3 1600 RAM
2x 128GB SSD (Mirrored Boot)
4x 4GB HGST NAS HDD (Mirror)

New HomeLab / NAS
==============
TrueNAS-SCALE-21.06-BETA.1
Ryzen 3700x
ASRock X470D4U2-2T MoBo
32GB DDR4 2666 ECC RAM
2x 128GB SSD (Mirrored Boot)
2x NVMe 512GB SSD (Mirror)
4x 8TB WD Red HDD (RaidZ2)
nVidia Quadro P2200

anodos

Sambassador

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

Cadet

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.

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

morganL

Captain Morgan

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

anodos

Sambassador

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

SantiCF

Cadet

Ryan Haver

Dabbler

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.

Источник

Permission issue — Can not apply permissions recursively

Truenas009

Cadet

Hi, can anyone help please?

I have Truenas Scale RC2 installed. I really like the software, only if i can get the permissions to work properly.

On my datasets when i apply a single user, it works ok, but as soon as i try to add a second user to the dataset with the option «Apply permissions recursively» ticked, I get the below errors, I can not figure out what i am doing wrong?

====================================
[EINVAL] filesystem_acl.dacl: Default ACL entries are required in order to apply ACL recursively.
remove_circle_outlineMore info.
Error: Traceback (most recent call last): File «/usr/lib/python3/dist-packages/middlewared/job.py», line 382, in run await self.future File «/usr/lib/python3/dist-packages/middlewared/job.py», line 420, in __run_body rv = await self.middleware.run_in_thread(self.method, *([self] + args)) File «/usr/lib/python3/dist-packages/middlewared/utils/run_in_thread.py», line 10, in run_in_thread return await self.loop.run_in_executor(self.run_in_thread_executor, functools.partial(method, *args, **kwargs)) File «/usr/lib/python3.9/concurrent/futures/thread.py», line 52, in run result = self.fn(*self.args, **self.kwargs) File «/usr/lib/python3/dist-packages/middlewared/schema.py», line 1267, in nf return func(*args, **kwargs) File «/usr/lib/python3/dist-packages/middlewared/plugins/filesystem_/acl_linux.py», line 626, in setacl return self.setacl_posix1e(job, data) File «/usr/lib/python3/dist-packages/middlewared/plugins/filesystem_/acl_linux.py», line 585, in setacl_posix1e verrors.check() File «/usr/lib/python3/dist-packages/middlewared/service_exception.py», line 62, in check raise self middlewared.service_exception.ValidationErrors: [EINVAL] filesystem_acl.dacl: Default ACL entries are required in order to apply ACL recursively.

NugentS

Wizard

I think that’s working as intended. ie welcome to the f’king mess that is POSIX ACL’s. Unintuitive, illogical and a disaster.
My opinion of course. Its all rooted in the past and hasn’t moved with the times.
There is documentation all over the web saying how to use these properly — which are to my mind mind basically gobbledegook and do not pass the «KISS» principle.

I would try and tell you how to do it properly — but frankly I don’t understand it (and not sure I want to)

Источник

Scale ACL + Samba is just flat out broken?

guemi

Dabbler

I recently reinstalled my home NAS from Core to SCALE as we’re in the process of switching to SCALE at work for our storage systems since Linux has better compability with our hardware.

I run a very simple setup at home. Two samba shares, one needs to be fairly locked down because I use a sync app on my phone to instantly upload any pictures I take via samba to my NAS as a backup.

It’s worked for years and it’s been smooth. Not so much with SCALE.

I installed Scale, imported the Pools, the datasets for previous shares are there — so far so good.

Create a new local user on the NAS simply called «cloudsvc».
Enabled it for Samba Authentication.
Create a SMB share, left S-1-1-0 at full control since I’ll be doing permissions on the dataset level — just as I did in CORE.
The folder shared is /mnt/STRIPED01/NETWORKSHARES/Cloud and the NETWORKSHARES dataset ACL looks like the following:

Go to windows, emty credential manager, delete all previous network shares with net use command for everything to be as good as new:

Try to go to \10.10.10.100 — gets prompted for username / password — enter cloudsvc and password:

Network share is visible, and the samba log shows the auth and confirms it’s OK and that the local INTERSTELLAR (NAS HOSTNAME) user was used:

<«timestamp»: «2022-07-10T13:11:40.246925+0200», «type»: «Authentication», «Authentication»: <«version»: <«major»: 1, «minor»: 2>, «eventId»: 4624, «logonId»: «0», «logonType»: 3, «status»: «NT_STATUS_OK», «localAddress»: «ipv4:10.10.10.100:445», «remoteAddress»: «ipv4:10.10.10.101:64919», «serviceDescription»: «SMB2», «authDescription»: null, «clientDomain»: «.», «clientAccount»: «cloudsvc», «workstation»: «TITAN», «becameAccount»: «cloudsvc», «becameDomain»: «INTERSTELLAR», «becameSid»: «S-1-5-21-3666039284-1560195053-518253317-20066», «mappedAccount»: «cloudsvc», «mappedDomain»: «.», «netlogonComputer»: null, «netlogonTrustAccount»: null, «netlogonNegotiateFlags»: «0x00000000», «netlogonSecureChannelType»: 0, «netlogonTrustAccountSid»: null, «passwordType»: «NTLMv2», «duration»: 4763>>

Try to enter the network share aaaaaand boom:

But if we added @Everyone with full permissions on the dataset?

Then it works great. And of course it does, it’s never checking any permissions.

getfacl confirms the user has access and is even OWNED by the user I am trying to connect with:
root@INTERSTELLAR[

]# getfacl /mnt/STRIPED01/NETWORKSHARES
getfacl: Removing leading ‘/’ from absolute path names
# file: mnt/STRIPED01/NETWORKSHARES
# owner: cloudsvc
# group: root
user::rwx
group::rwx
other::rwx

]# ls -lh /mnt/STRIPED01/NETWORKSHARES
total 8.5K
drwxrwxrwx 12 cloudsvc root 17 May 7 12:05 CLOUD

This is the exact same process I’ve done on multiple CORE installs and it just works — Is SCALE ACL’s just not ready to be used with Samba properly?

When going through SMB and hitting «View Filesystem ACL» in the UI, I get to /mnt/STRIPED01/NETWORKSHARES/CLOUD which is the actual folder that’s being shared — but I made sure to mirror the settings of the NETWORKSHARES ACL on to that one, so there isn’t a conflict there either.

I also tried directly sharing the path /mnt/STRIPED01/NETWORKSHARES with SMB just in case — but no dice.

anodos

Sambassador

guemi

Dabbler

I’ve never entered any in FreeBSD or in Linux so shouldn’t be any, nope.

I had different usernames in FreeBSD but that’s about it.

I’ll try stripping all ACL’s and redoing them — maybe something carried over from FreeBSD Install on the pools and dataset?

guemi

Dabbler

No dice in redoing them, so I figured OK let’s just make a new dataset and try — and when trying to set ACL there it’s also won’t let you progress because:

[EINVAL] filesystem_acl.dacl: Presence of [USER_OBJ] entry is required.
[EINVAL] filesystem_acl.dacl: Presence of [GROUP_OBJ] entry is required.
[EINVAL] filesystem_acl.dacl: Presence of [OTHER] entry is required.

All 3 which are clearly there.

I keep googling and find forum threads were you anodos is talking about a UI rewrite from around spring/summer 2021 for 21.08. I’m running 22.02.2.1 — has this UI rewrite not happened before?

guemi

Dabbler

Also tried using POSIX RESTRICTED preset ACL, and just add the user to it, and then share that dataset:

But still no permission. There seems to be massive issues with permissions in SCALE for sure.

Which isn’t end of all worlds in my private use, and the benefits of other additions to scale over core certainly out weighs this little problem since I can just temporarily throw a VPN on my phone instead of accessing samba over the internet like previously — but my hopes were to migrate our 4 storage machines at work to SCALE and this just isn’t nowhere near business ready, adding the mess that is Active Directory to this would probably cause even more trouble.

Which also isn’t exactly a deal breaker, but we’ve had some trouble with AQC107 10 gbit/s nics on CORE and I do like trying out and using the latest and greatest and I really like the idea behind SCALE.

guemi

Dabbler

Further more, tried to limit on SMB Share access level.

Allow file-system permissions for everyone to 777 and then removed S-1-1-0 from the Share Permissions and tried to add INTERSTELLARcloudsvc to full permissions.

Which authenticates correctly according to samba:
<«timestamp»: «2022-07-10T15:39:10.537669+0200», «type»: «Authentication», «Authentication»: <«version»: <«major»: 1, «minor»: 2>, «eventId»: 4624, «logonId»: «0», «logonType»: 3, «status»: «NT_STATUS_OK», «localAddress»: «ipv4:10.10.10.100:445», «remoteAddress»: «ipv4:10.10.10.101:56339», «serviceDescription»: «SMB2», «authDescription»: null, «clientDomain»: «TITAN», «clientAccount»: «cloudsvc», «workstation»: «TITAN», «becameAccount»: «cloudsvc», «becameDomain»: «INTERSTELLAR», «becameSid»: «S-1-5-21-3666039284-1560195053-518253317-20066», «mappedAccount»: «cloudsvc», «mappedDomain»: «TITAN», «netlogonComputer»: null, «netlogonTrustAccount»: null, «netlogonNegotiateFlags»: «0x00000000», «netlogonSecureChannelType»: 0, «netlogonTrustAccountSid»: null, «passwordType»: «NTLMv2», «duration»: 2634>>

But still does not grant access to the share.

Tried entering the wrong password just to make sure it actually authenticated the local TrueNAS uiser, and yup — log then tells me wrong password:

<«timestamp»: «2022-07-10T15:39:14.280395+0200», «type»: «Authentication», «Authentication»: <«version»: <«major»: 1, «minor»: 2>, «eventId»: 4625, «logonId»: «0», «logonType»: 3, «status»: «NT_STATUS_WRONG_PASSWORD», «localAddress»: «ipv4:10.10.10.100:445», «remoteAddress»: «ipv4:10.10.10.101:56339», «serviceDescription»: «SMB2», «authDescription»: null, «clientDomain»: «TITAN», «clientAccount»: «cloudsvc», «workstation»: «TITAN», «becameAccount»: null, «becameDomain»: null, «becameSid»: null, «mappedAccount»: «cloudsvc», «mappedDomain»: «TITAN», «netlogonComputer»: null, «netlogonTrustAccount»: null, «netlogonNegotiateFlags»: «0x00000000», «netlogonSecureChannelType»: 0, «netlogonTrustAccountSid»: null, «passwordType»: «NTLMv2», «duration»: 2398>>

If I throw S-1-1-0 ALLOWED back to the SHARE ACL and not touching the dataset permissions as they’re already set to allow everyone, I can then access the share with the cloudsvc accound.

Very very strange.

morganL

Captain Morgan

Were you on an old CORE version?

There been a move away from allowing root as an SMB user. Can you remove root user and group and see if the problems persist.

SOLVED — FreeNAS-11.3-U5 —> TrueNAS CORE 12.0-U4: Can’t access to my SMB shares as «root» anymore. Can’t access at all actually!

anodos

Sambassador

POSIX1E ACL is incorrect above. It grants de-facto 770 permissions with root:root on all paths below the root. No one other than root will be able to access files. POSIX1E acltype only exists in SCALE so this dataset didn’t come from core. If you want to use POSIX1E acltype, then you should probably add a default explicit group entry for the default SMB group builtin_users to the path and apply recursively.

If you are using NFSv4 acltype (the type default in FreeBSD), then you can set an inheriting GROUP entry for builtin_users to do the same. One difference between Linux and FreeBSD is whether gid for a new file or dir is inherited from parent dir or set based on gid of creating process. Former is FreeBSD behavior and later is Linux behavior.

In next 22.02 release I have changed ZFS so that in case of NFSv4 ACLs we keep the FreeBSD behavior (since this will ensure permissions behavior are consistent across both platforms when NFSv4 ACLs are selected) to ease migrations for users who are not taking advantage of flexibility of ZFS ACLs to set explicit group permissions rather than relying on OS implementation details for permission (via GROUP@ entries).

emsicz

Explorer

I’m trying to figure this out myself right now. I don’t understand how this was even released, I can’t get anything to work. As long as I keep using the traditional ACL, it works as expected. As soon as I try to define users and groups in non-traditional ACL, I can never get past the error dialog that keeps telling me some groups need to be added or whatever. The tooltips are useless:

anodos

Sambassador

I’m trying to figure this out myself right now. I don’t understand how this was even released, I can’t get anything to work. As long as I keep using the traditional ACL, it works as expected. As soon as I try to define users and groups in non-traditional ACL, I can never get past the error dialog that keeps telling me some groups need to be added or whatever. The tooltips are useless:

I work on backend details, not the webui. I’ll file a bug ticket about the webui team and see if they can improve this.

Big picture with POSIX (not NFSv4 ACLs), you have two separate lists:
1. ACCESS — applies to current directory / file
2. DEFAULT — applies to newly created files / directories in the current directory.

And there are six different qualifiers that each entry can have:
1. USER_OBJ (the owner of the file)
2. USER (a separate user)
3. GROUP_OBJ (the group of file)
4. GROUP (a separate group)
5. OTHER (anyone who isn’t owner, member of group, or in another ACL entry)
6. MASK (sets the maximum permissions for additional group specified in the ACL)

From the standpoint of what you see in the GUI, the ACCESS acl gives you the permissions for the current path (dataset mountpoint). The DEFAULT ACL tells you what any existing file or newly created file will get. Basically you need to have entries for both. There are also mandatory entries in a POSIX1E ACL:

1. USER_OBJ
2. GROUP_OBJ
3. OTHER

These must exist in ACL and there may only be one ACCESS and one DEFAULT entry for each other them. The backend also requires that a MASK be defined explicitly (because we don’t want implicit permissions behavior).

Yes, this is quite complex. I think the NFSv4 ACL option is significantly simpler in that there’s one list and you choose explicitly whether you want particular entries to inherit.

You can change acltype in the storage plugin.

That said, this is the way that POSIX1E ACLs work in general on Linux, and since we receive data rsynced from Linux servers (and potentially ZFS replication from other servers using ZoL), we have to support them in the webui.

emsicz

Explorer

I work on backend details, not the webui. I’ll file a bug ticket about the webui team and see if they can improve this.

Big picture with POSIX (not NFSv4 ACLs), you have two separate lists:
1. ACCESS — applies to current directory / file
2. DEFAULT — applies to newly created files / directories in the current directory.

And there are six different qualifiers that each entry can have:
1. USER_OBJ (the owner of the file)
2. USER (a separate user)
3. GROUP_OBJ (the group of file)
4. GROUP (a separate group)
5. OTHER (anyone who isn’t owner, member of group, or in another ACL entry)
6. MASK (sets the maximum permissions for additional group specified in the ACL)

From the standpoint of what you see in the GUI, the ACCESS acl gives you the permissions for the current path (dataset mountpoint). The DEFAULT ACL tells you what any existing file or newly created file will get. Basically you need to have entries for both. There are also mandatory entries in a POSIX1E ACL:

1. USER_OBJ
2. GROUP_OBJ
3. OTHER

These must exist in ACL and there may only be one ACCESS and one DEFAULT entry for each other them. The backend also requires that a MASK be defined explicitly (because we don’t want implicit permissions behavior).

Yes, this is quite complex. I think the NFSv4 ACL option is significantly simpler in that there’s one list and you choose explicitly whether you want particular entries to inherit.

You can change acltype in the storage plugin.

That said, this is the way that POSIX1E ACLs work in general on Linux, and since we receive data rsynced from Linux servers (and potentially ZFS replication from other servers using ZoL), we have to support them in the webui.

Thanks for the explanation, it does give some pointers, but it doesn’t really solve anything. It’s not that I may have all these entries, it’s that I apparently must have these entries in the UI. I can’t just contemplate to have an option to include like 9 different ACEs before pressing submit, it’s that the UI will give me non human friendly errors if I don’t include all of those. That being said, I tried and failed with that approach too.

Also, I still don’t understand what the MASK is for. The explanation of «MASK (sets the maximum permissions for additional group specified in the ACL)» tells me nothing. Maybe I’m just dumb, or I’m googling for wrong keywords, but I don’t get what «maximum permissions» you’re on about for what «additional group». What if I have like 10 groups in there. And how do I even populate all these fields in the UI?

Consider the following model scenario:

1. TrueNAS root user sets up datasets. Those are then owned by root.
2. TrueNAS root tries to set up SMB shares in the UI.

This super-basic use case comes with pretty non-basic requirements:

1. Create individual TrueNAS users for people and apps that are expected to manipulate the data. Already this is getting convoluted because of the weird user/group concept where user «john» also creates a group named «john» which is weird and strange concept to grasp. Some groups and users are pre-created and sometimes are visible and sometimes are not visible. And then there’s a group called «wheel» which is somehow normal but I don’t understand why is it called wheel. I don’t see any wheels in there, nothing is spinning in the UI, none of my new users are in the group wheel (because they are in their own groups called the same as the user itself). None of this makes any sense, so I’m trying to ignore it but it leaves me feeling insecure about my data.
2. Then I need to set up SMB shares where I need to deal with the fact that SMB has it’s own ACLs that are apart from filesystem ACLs and the UI doesn’t make this clear at all. The SMB share has a checkbox «Enable ACL» so which ACLs is it referring to and what happens if it’s disabled? How does it even make sense to have SMB share with disabled ACL? Although this separation of ACLs is implemented, it is repeatedly recommended around here to not use it and that ACEs should be entered and maintained for the file system ACL only.

To say this simply, it’s 23:50 at night where I’m at and I’m stuck trying to create a simple share on TrueNAS for last 6 hours and I don’t care about any of this crap. If I wanted this level of granularity, I would’ve used a pure distro and spent my youth configuring dozens of different plugins and configs and gloat about it on distro forums. The purpose of using TrueNAS is to be shielded from this methinks.

Источник

Cannot set ACL permission on Imported Pool

Carlton_R

Cadet

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.

anodos

Sambassador

Carlton_R

Cadet

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?

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

Cadet

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

Wizard

Carlton_R

Cadet

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 Userroot) and the username (Unix Userroot).

— 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.

Источник

Access Based Share Enumeration ACL setup

gegtor

Explorer

I’m trying to hide samba shares from users who don’t have access to them

I found access based share enum = yes option on the internet and sure enough, FreeNAS has such option exposed to the GUI in share configuration

After setting it on users still see shares they don’t have real access to

I presume it comes from incorrect ACL config

I tried deleting everyone@ ACL entry but I get Error: [EINVAL] At least one inheritable ACL entry is required

ACLs are a new concept to me because I’m used to just simple group bases access

What would be the correct ACL setting to limit users ability to see shares?

anodos

Sambassador

Graydens

Cadet

Were you able to fix that, I have the same problem with windows exporer. If i connect via ftp (Filezilla) it works like it should

Please let me know.

gegtor

Explorer

Were you able to fix that, I have the same problem with windows exporer. If i connect via ftp (Filezilla) it works like it should

Please let me know.

Yes I was successful and it works just fine

I followed the advice from @seanm

1) add «access based share enum=yes» as an aux parameter on the FooBar share.
2) from the shell, use ‘net usersidlist’ or ‘net groupmap list’ to determine the SID of a local FreeNAS user or group ex: S-1-5-21-7567469271-2383756280-2683756379-1001
— add a ‘share permission’ for the SID (remember this sets maximum permissions) and remove the default one:

sharesec Test -a S-1-5-21-7567469271-2383756280-2683756379-1001:ALLOWED/0/FULL
sharesec Test -r S-1-1-0:ALLOWED/0x0/FULL

3) stop/start samba

anodos

Sambassador

Yes I was successful and it works just fine

I followed the advice from @seanm

Follow those steps for every share and it will work 🙂

gegtor

Explorer

anodos

Sambassador

Phil1295

Explorer

I tried this setting in the most recent 12.x release.
By enabling this option in the Share GUI check box, or by adding

either in Share, SMB service or both auxiliary params, the shares are still visible to users without read permission

I always manage ACLs through TrueNAS GUI rather than MMC snapins. Is there a way to properly make it work from TrueNAS side in 12.0 ?

Thank you a lot

anodos

Sambassador

I tried this setting in the most recent 12.x release.
By enabling this option in the Share GUI check box, or by adding

either in Share, SMB service or both auxiliary params, the shares are still visible to users without read permission

I always manage ACLs through TrueNAS GUI rather than MMC snapins. Is there a way to properly make it work from TrueNAS side in 12.0 ?

Thank you a lot

Phil1295

Explorer

I see, in fact Share ACL is set to allow any by default
However, even when listing shares from an Android device for example, the share is listed despite user not having read permissions. Will the windows SID apply here ? I doubt.

Also, will the share ACL take precedence over the File System ACLs for windows ? That is, they must both match with same configured groups to allow / deny ?

Phil1295

Explorer

@anodos
I also noticed another issue, not sure if it is related to TrueNAS only:
Under a Windows machine, if two users login under the same machine, they will each see the home share of their own + the one from the other user listed AND ACCESSIBLE
However, when user1 accesses user2 home share, it will see his own files (user1) listed. Same when user2 accesses user1 home share, he actually see his own files

This is really a wired issue.
Can you also clarify please the above question about access based share enum ?

anodos

Sambassador

Phil1295

Explorer

Thank you for your help
I took time to test and all is working perfectly, even from an android device in fact, which is logical because the permissions are set in TrueNAS

Here are the steps from the GUI for people looking at it:

1. when creating the share (or edit for existing shares), check «Advanced Options / Access Based Share Enumeration»
2. properly set the share access permissions under Share option «Edit Filesystem ACL» at your liking
3. now, this is the most important part, use the Share option «Edit Share ACL»
4. edit the first default entry (you cannot delete it in GUI, only edit it) by either:
   • entering the SID of the group or user allowed to access/list the share
   • or specifying the group/user name and the Domain name: the SMB service must be enabled in this case so that TrueNAS can query the proper SID, else you will get an error
5. Set the permissions to what you want for the user/group: FULL, READ, CHANGE
6. Set the Type to ALLOWED to allow that group/user or DENIED to specifically deny it
7. Repeat steps 4 to 6 for any other group you want to add
8. restart the SMB service for the changes to take effect and to reflect on currently connected clients

You can optionally get the SID of each user/group when on a domain, by using the below commands in shell:

@anodos :
Can you confirm the above steps and that setting the ALLOWED groups is enough (the default will be DENIED for any other non specified user/group) ?
Seems logical to me and that’s what I verified in my tests

anodos

Sambassador

Thank you for your help
I took time to test and all is working perfectly, even from an android device in fact, which is logical because the permissions are set in TrueNAS

Here are the steps from the GUI for people looking at it:

1. when creating the share (or edit for existing shares), check «Advanced Options / Access Based Share Enumeration»
2. properly set the share access permissions under Share option «Edit Filesystem ACL» at your liking
3. now, this is the most important part, use the Share option «Edit Share ACL»
4. edit the first default entry (you cannot delete it in GUI, only edit it) by either:
   • entering the SID of the group or user allowed to access/list the share
   • or specifying the group/user name and the Domain name: the SMB service must be enabled in this case so that TrueNAS can query the proper SID, else you will get an error
5. Set the permissions to what you want for the user/group: FULL, READ, CHANGE
6. Set the Type to ALLOWED to allow that group/user or DENIED to specifically deny it
7. Repeat steps 4 to 6 for any other group you want to add
8. restart the SMB service for the changes to take effect and to reflect on currently connected clients

You can optionally get the SID of each user/group when on a domain, by using the below commands in shell:

@anodos :
Can you confirm the above steps and that setting the ALLOWED groups is enough (the default will be DENIED for any other non specified user/group) ?
Seems logical to me and that’s what I verified in my tests

Источник

SCALE Beta ACL and Permissions Errors

SpinMop

Cadet

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’

Error: [EINVAL] filesystem.setacl.path: The specified path is a ZFS pool mountpoint «(/mnt/ )» [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

Patron

SpinMop

Cadet

littleNewton

Cadet

I got this problem too.

I don’t know very well about ACL settings.

morganL

Captain Morgan

littleNewton

Cadet

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.

I don’t know why.

HeyRay2

Cadet

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.

Main NAS
======
TrueNAS-12.0-U4
Core i3-4170
ASRock H97 Pro4 MoBo
32GB DDR3 1600 RAM
2x 128GB SSD (Mirrored Boot)
4x 4GB HGST NAS HDD (Mirror)

New HomeLab / NAS
==============
TrueNAS-SCALE-21.06-BETA.1
Ryzen 3700x
ASRock X470D4U2-2T MoBo
32GB DDR4 2666 ECC RAM
2x 128GB SSD (Mirrored Boot)
2x NVMe 512GB SSD (Mirror)
4x 8TB WD Red HDD (RaidZ2)
nVidia Quadro P2200

anodos

Sambassador

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

Cadet

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.

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

morganL

Captain Morgan

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

anodos

Sambassador

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

SantiCF

Cadet

Ryan Haver

Dabbler

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.

Источник

Error: EINVAL: invalid argument, read

react-native init gcLists

E:gcLists>npm -v
5.5.1
E:gcLists>yarn -v
1.2.1
E:gcLists>react-native -v
react-native-cli: 2.0.1
react-native: 0.49.5

npm install --save-dev eslint --verbose

npm http fetch GET 304 https://registry.npmjs.org/slice-ansi 104ms (from cache)
npm verb correctMkdir D:UsersgregAppDataRoamingnpm-cache_locks correctMkdir not in flight; initializing
npm verb lock using D:UsersgregAppDataRoamingnpm-cache_locksstaging-255cd84f0d76b150.lock for E:gcListsnode_modules.staging
npm info lifecycle semver@5.4.1~preuninstall: semver@5.4.1
npm info lifecycle semver@5.4.1~uninstall: semver@5.4.1
npm verb unbuild rmStuff semver@5.4.1 from E:gcListsnode_modules
npm verb unlock done using D:UsersgregAppDataRoamingnpm-cache_locksstaging-255cd84f0d76b150.lock for E:gcListsnode_modules.staging
npm verb stack Error: EINVAL: invalid argument, read
npm verb stack     at D:UsersgregAppDataRoamingnpmnode_modulesnpmlibutilsgently-rm.js:275:7
npm verb stack     at D:UsersgregAppDataRoamingnpmnode_modulesnpmnode_modulesiferrindex.js:13:50
npm verb stack     at D:UsersgregAppDataRoamingnpmnode_modulesnpmnode_modulesgraceful-fspolyfills.js:287:18
npm verb stack     at FSReqWrap.oncomplete (fs.js:154:5)
npm verb cwd E:gcLists
npm verb Windows_NT 6.1.7601
npm verb argv "C:\Program Files\nodejs\node.exe" "D:\Users\greg\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js" "install" "--save-dev" "eslint" "--verbose"
npm verb node v8.7.0
npm verb npm  v5.5.1
npm ERR! code EINVAL
npm ERR! EINVAL: invalid argument, read
npm verb exit [ 1, true ]

npm ERR! A complete log of this run can be found in:
npm ERR!     D:UsersgregAppDataRoamingnpm-cache_logs2017-11-03T02_38_08_842Z-debug.log

6 ответов

Лучший ответ

yarn add eslint

npm cache clean

rm -rf node_modules package-lock.json
npm i