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
and not enabling and using the root one.
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
TEST1 and TEST3 are created with the above user, TEST2 with the root one (and im guessing why is working, password is disabled now )
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
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
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.
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?
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 )… 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
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.
)
Sorry i obvious make hard time for you to understand what I mean. I try to explain again hope i can be clearer