How to properly create an "administrator" account?

Dealing with Core to EEL migrations, after config upload my truenas_admin account has been deleted (with other i think minor things).
I create another user, “copied” the settings from the root (obv followed those tips too), checked everything were ok and disabled password for the root. The homedirectory has been created in a random dataset.
The only difference i can see from GUI, is that this new account is not a built in user.
So far so good, but facing some replication issue in another thread i realize that this occur only using this specific account
image
and not enabling and using the root one.

What i’m missing?

Not sure.

Can you verify you’ve followed the instructions here.

Which step did not work for you??

Actually with this account i didn’t encounter any other limitations, on routine operation. At least for the moment!
This Is how Is actually setup my user:

On your link, the guide suggest to create a group with local administrator property, can be just that the problem? Honestly i realised that a group gid950 has been deleted, but watching on another Scale fresh was a group without any setting (neither the local administrator)… i tried to ricreate but nothing change; btw the working root account didn’t have It, Is just part of wheel group too.

I have also read that:

Also assigned when manually creating an admin user if logged in as the root user account after upgrading from a pre-22.12.3 release of SCALE or migrating from CORE to SCALE

Don’t know how this should work and if Is applicabile to my situation

If you follow that guide and find a problem… I can see if someone can help or ask you to report a bug.

This attempt fail too

TEST1 and TEST3 are created with the above user, TEST2 with the root one (and im guessing why is working, password is disabled now :thinking: )

Honestly i have opened a ticket like 20 days ago, during this time i have made other attempt and managed to “isolate” the TLS problem only during the establish of a connection on CORE, but this problem is persisting on SCALE.
Those 2 things happen during the attempt of create e PULL replication task

Trying to simplify the steps and where it fails.

You’ve
creacted the group
Assigned administrative privileges
created the user and assigned to the group

everything looks good.

No ssh admin allowed?

@HoneyBadger Can you see the issue or suggest a way of testing?

For be 100% clear, don’t know if can be relevant, first i create the user assigning him the built-in-administrator Auxiliary Groups, wheel as primary, then tried with assigning him a group with local administrator too, and the problem persist.
Everything actually is how you can see in the screenshot, plus the truenas_admin group (if there is a better way to provide those info let me know!!).
I didn’t encounter any other problem, at least until now

Sorry didn’t understand here what you mean. I can establish the SSH connection but can’t access to datasets list

So you can use the new user to admin the box?

You just can’t see the datasets?

Can you check the permissions on the datasets?

As far as I can understand, you have a problem specifically when you want to set up a replication task, because the Replication Task Wizard window informs you that you lack permission to see a list of datasets to replicate.

In the screenshot your chosen SSH Connection is named “test”.
Can you please show how you set the SSH Connection up.
It’s in Credentials → Backup Credentials → SSH Connections.

  • yep, without apparently any issue
  • yep, and only if i PULL from the destination system. With PUSH works
  • i will asap!!

Excatly, as said above, only on PULL.
(from the remote machine)

Both pools has root nor as owner and group.
Most childs datasets same, just a couple of exceptions.
Effectively the new user is not present in any permission (i use another account for access data), but i tried to add the root group on him without change.
This really mean that i must add him in every ACL? :smiling_face_with_tear:

1st lets try it and confirm that’s the issue.

Then… the question is what is the best way to set up pool and datasets for administrator to have replication rights?

Hoping not asking a really dumb thing (as linux newbie), my question is a full administrator shouldn’t be capable to access those data despite the ACL, for this kind of purpose?
For avoid any other mess (honestly im bit confused by what i’m seeing, and i’m starting leave my comfort zone), i’m using a dataset that i don’t need anymore, the iocage inherited from Core.

Adding an ACL entry davide_admin, with full control and recursive flags, don’t change anything.
Changing and applying the owner with davide_admin, also not change anything. Every dataset seems forbidden.
Just for add more info (or more confusion :smiling_face_with_tear: )… same user can access every datasets for internal replication, nor PUSH or PULL. I can’t get the logic involved.

On the target machine, pool and datasets has been created by the truenas_admin, the ownership is assigned to root nor for user and group… and if i try to PULL with SSH connection using the truenas_admin user, i can see every pool/datasets without issue.

Pools has been obv made in the previous Core system, root user, at time i was at beginning of my Truenas journey and i don’t wanna omit that is possible that i have could made some layout mistake that now is impacting, but in case i really can’t understand what

There are restrictions… for example a storage admin should not have access to their HR files. However, a storage admin can change settings… but we also try to keep a log of that.

For your issue… is it now only the ability to push with SSH connections?

Lets try to focus on a single issue, resolve it or report a bug.

Pratically yes. Connecting from another truenas SCALE with this account via SSH, to perform a PULL backup replication, end with an access denied to datasets.
Despite same account can access those datasets for internal replication, or can PUSH those datasets to the other system without any issue.
Actually i’m using the root account to workaround this

Being more specific

Pull initiated by CORE 13.0 TrueNAS not being accepted by SCALE 24.10.0.2 NAS.

Is that correct?

It works with root account on both systems.

It does not’ work with “truenas_admin” on both systems?

no, edited a bit last post, hope will be clearer

No, access denied to datasets occur through 2 Scale EEL system, where the remote system try to PULL with an account that is not root or truenas_admin (Pulling from Core give other problem and not seems working with the root user too, but i need to test more for confirm)

yes, using root account avoid the problem, connecting on the fresh Scale using truenas_admin the problem didn’t occur anyway

the system migrated from Core don’t have a truenas_admin user, it has been deleted uploading config file.

So, CORE 13.0 system can only PULL from SCALE 24.10 system using root account on both systems. I assume this may be the case if roles are reversed to.

  • this may be a restriction, but should be documented better. If this is an accurate description, please confirm.

Not correct :laughing: Sorry i obvious make hard time for you to understand what I mean. I try to explain again hope i can be clearer

I have 3 system:

  • 1 Scale EEL, sidegraded from Core 13.3, config file uploded and not using the default truenas_admin user → A
  • 1 Scale EEL, just a fresh install → B
  • 1 Core → C

A Is the main system, B and C are just backup machine.
Every systems are in the same LAN (for the moment, B Is planned to be in another place).

  • A can PUSH to B and C without issue
  • A can PULL from B using truenas_admin credentials of B
  • B can’t PULL from A, works only using root account and not the “custom admin” → the datasets access denied error
  • C can’t PULL from A → always getting TLS error mentioned in the ticket

Im not concerned about C (if Is a Core limitation i will just upgrade this system to Scale), im more interested on fix the problem with B

Thanks… that clarifies it. So, B can’t pull from A with admin account is the only remaining issue.

But do the datasets on A have permissions for Trunas_admin?