[EINVAL] sharing_smb_setacl.share_acl.1.ae_who_id: User or group does must exist and be an SMB account

TrueNAS General
,
1

Platform: TRUENAS-MINI-3.0-X+
Version:Dragonfish-24.04.1.1
Please bear with me, I am new to TrueNAS

First I installed FreeNAS and later upgraded to TrueNAS Core, then TrueNAS Scale.
I (re)recrated the datapool and datasets in the most easy fashion, using just the default parameters, The datasets were created with presets SMB and automatic SMB share creation.

Now the issue that I am facing is this:
I am unable to create SMB ACLs for any local user but the first user I created (likely before any upgrades).
When I try to create an ACL for another local user I see them in the list (as they have SAMBA authentication enabled), I can select them and select the rights I want, but when I click save, I get this error:
[EINVAL] sharing_smb_setacl.share_acl.1.ae_who_id: User or group does must exist and be an SMB account.

Under “more info” it says:
Error: Traceback (most recent call last): File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 198, in call_method result = await self.middleware.call_with_audit(message[‘method’], serviceobj, methodobj, params, self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 1466, in call_with_audit result = await self._call(method, serviceobj, methodobj, params, app=app, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 1417, in _call return await methodobj(*prepared_call.args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/lib/python3/dist-packages/middlewared/schema/processor.py”, line 187, in nf return await func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/lib/python3/dist-packages/middlewared/schema/processor.py”, line 47, in nf res = await f(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/lib/python3/dist-packages/middlewared/plugins/smb.py”, line 1828, in setacl verrors.check() File “/usr/lib/python3/dist-packages/middlewared/service_exception.py”, line 70, in check raise self middlewared.service_exception.ValidationErrors: [EINVAL] sharing_smb_setacl.share_acl.1.ae_who_id: User or group does must exist and be an SMB account.
What should have been easy and straightfowrard - creating datasets and SMB shares, then defing access rights - has become a mess.

Could anybody point me in the right direction for a solution?

Thanks for any help.

2

Nothing?
No ideas? No suggestions whatsoever?
Pretty disappointing for a product that aims to be professional…

3

Hi Giorgio, I’ll see if I can help but I have a few questions first.
When you upgraded from FreeNAS to CORE, how did you do this? Did you follow the instructions to upgrade from major release to next major release until you reached 13.0-U6.1 before migrating the SCALE? Or did you jump releases?
Did you use the UI?
Why did you recreate new pools? If you import your config file it should have recreated your pools, which then allows you to import your data to those pools.
I just want to understand how you got where you are.

4

Thanks for your reply bella.
I did all the updates/upgrades via the GUI.
So I guess I followed procedure, always installing the latest that the GUI suggested until 13.0-U6.1. Even did the upgrade to SCALE via the GUI.
I recreated the pools because I had GELI encryption and since that was no longer supported I lost access to my pool.
Hope this answers your questions.

Any ideas how to fix this, short of reinstalling from scratch?
This smells like a bug really.

Thanks for your help.

5

Okay, so you didn’t do the conversion from GELI encrypted to ZFS encrypted before upgrading to CORE 13.0 then. Unfortunately, I don’t know how you can regain access to your data.

Our documentation in the Migration Prep article clearly states you must address GELI encryption while in a CORE 12.x release before upgrading to CORE 13.0-Ux or 13.3 because you lose access to that data if you do not convert from GELI encryption.

I’m sorry I cannot help you with this. Perhaps one of the experienced forum users can offer suggestions.

6

Reworded my post:
I am not sure I understand the issue. Isn’t the GELI vs. native ZFS encryption parts essentially history, certainly a problem the OP faced, but those pools have been recreated and the GELI issue ought not to be an issue anymore.

The issue now appears to be that the OP is unable to modify ACLs on a SMB share related to users other than the initial user. Trying to do so results in the posted traceback.

Does this happen even with a new user created since updating to SCALE?

7

The issue here is NOT the data I lost. I am not sure I remember this properly but likely the conversion from GELI to ZFS involved decrypting everything to another pool and I could not do that. But again, this is not the issue here.
The subject of this post is me being unable to create SMB shares ACLs for local users other that that one local user that I created before migrating.

How can I fix this so I can create ACLs for any user?

8

Thanks neofusion, you understood this right.

Yes, this happens with users I created after the upgrade to SCALE.

9

Which ACLs are you editing, the Share ACLs or the Filesystem ACLs? In my home install I never touched the Share ACLs at all, instead going directly to the Filesystem ACLs and doing the changes I wanted there, it offered a better UI for my needs.

You get to the Filesystem ACLs easily by clicking Shares in the lefthand menu and then on the checkered shield icon on the row of the SMB share you want to edit access to, the tooltip/hover text should be “Edit Filesystem ACL”.

Admittedly, that does not explain the error, but perhaps it can offer a way around it, unless of course you get this error in the Filesystem ACL window…

10

Thanks.
The issue arises with Share ACLs.
I tried and I can change the Filesystem ACL for any user.
I did a quick test and user X can see the share but cannot see any files once he opens the share with access right Deny Full Control.

What I would really like is that user X cannot even see the share when he scans the server.

Is that possible without Share ACLs?

11

@Giorgio what I believe you are looking for here is Access Based Share Enumeration under Advanced Settings. You may have to change the Purpose from a default/template to No presets in order to be able to freely select them.

image

With regards to your inability to select these users from your Share ACL menu, are you able to collect a debug file (System → Advanced → Save Debug) and submit it as a bug report?

And to double-check the workflow:

  1. Install with CORE, create one or more users
  2. Upgrade to SCALE
  3. Create a new user
  4. Attempt to provision access to the users through Share ACL - CORE users work, SCALE users do not
12

Thanks @HoneyBadger . You got the workflow almost right.

  1. Install with FreeNAS, create a local user,
  2. Upgrade to Core
  3. Upgrade to Scale, create more users
  4. Attempt to provision access to the users through Share ACL - FreeNAS user works, SCALE users do not

As for the Access Based on Share Enumeration, I activated that, but meanwhile I hit another issue with my Ubuntu 22.04 laptop - it does not let me mount shares any more - says something like unable to obtain the list of shares, connection refused… I will try to figure that one out tomorrow and then I can see if your option does what I want.
Thanks for your help so far.

13

OK, so the Filesystem ACLs seems to be a working workaround.
But I worry what other bad surprises I might have later on. So I hesitate to reinstall TrueNAS entirely.
Would someone have a fix for the SMB Shares ACL issue?

14

Hi @Giorgio!

I noticed the error that you describe on my system as well: I could not create/modify any share based ACLs to contain users, that had been created after a transition from CORE to SCALE.

Updating from 24.04.1.1 to 24.04.2 (which came out about a week ago) resolved the issue for me.

Cheers,

Emre

1 Like
15

Thanks Emre.
Yes 24.04.2 seems to have solved this issue.