Hey, as the title says, it’s with permissions that i have problems.
I did a fresh install of SCALE (EE 24.10.2.1) and imported my pool from my old CORE install. That worked although 1 drive didn’t get a proper label(?) but i was able to add the disk back since the ui showed one available disk. Since i only had the pool disks hooked up, i figured it was safe enough. Hit replace, added the available drive and after 12 hours of resilvering it was all good.
After that i was looking into setting up fresh users and apps when i noticed something strange on the datasets in my pool. One dataset has Unix Permissions, shows user - 1000 / group - 1000 / other. My other dataset has NFSv4 Permissions, shows everyone@ / owner@ - 1000 / group@ - 1000 / User - 989 / everyone@
My Marine Dataset
I checked in credentials-> users and didn’t find any when searching for 1000 or 989. So they don’t exist? Since this is still a fresh install with only 1 user made i would rather fix things now before setting things up more permanently.
This is the Core pool in imported to Scale. I’ll have to check and move potential data out of the iocage dataset at some point but that’s for later when things are solved.
You could try creating new users to match existing ID, by specifying the user ID while creation.
Alternatively, since its only few datasets, you can simply create the new users as normal and assign the permissions on the datasets (recursively - if applicable based on your scenario)
I’d just create some new users (with new UIDs) and then change the permissions on the datasets recursively. That is as long as you remember who 1000 and 989 were and what they did on your old system.
Sadly i don’t remember which users they were, i see the same users on my pool itself as on the Marine dataset so i would still have that problem.
Seeing how my pool has nearly filled up though. I was going to add 6 new drives for a second pool and share the data once everything was in order. Maybe it’s safer then to just add the new pool, transfer all the data to the new pool, erase the old pool and remake it with proper permissions?
That said, i’m not sure how easily you can transfer files locally. I know and am able to transfer them with my pc as an intermediary but i feel like it would be silly to have it go over the network for that. Perhaps winscp or something like it could help?
I’ll wait to hear what people’s thoughts are on it before i proceed as i don’t want do something wrong simply because i didn’t know about it.
Edit: I do know 1 user which is Jerren the user i tend to use for my SMB and it’s the one that i made fresh on Scale. Considering SMB works atm without adding that user, i would say that user is one of the two but i don’t like the idea of having a random user have acces to it so i’m leaning more to move it all to a new pool and destroy and remake the old pool idea now
Filesystems don’t actually store user names and group names.
In Windows they identify accounts by SID.
In MacOS, Linux, and BSD they are identified by uid and gid. In unix-like operating systems the conversion of these IDs into human-friendly names is handled by NSS (c.f. nsswitch.conf). For home users, this basically means the /etc/passwd file.
If you lose your original configuration file, there is no way to regenerate the passwd file with the values from your original system. Without this file, the TrueNAS permissions manager will show the raw uids and gids because there is no way to identify them. If you create a new user with the same name as your old user account, it will also not work correctly because the uid will most likely not be the same as the old uid.
This is not strange or unusual. It’s the way that it works on all computers.
My thought was indeed that there would be no old user names or group names attached to the pool since it’s a fresh Scale install. I have a config file from Core but haven’t tried uploading that config to Scale yet because i wanted to set things up properly from the get go and not rely on what i fumbled through on Core over the years.
Which is why i think it’s strange when importing the pool from Core into Scale it shows differing permissions even though i don’t remember setting anything up on them. The only action i performed with that pool is import it in Scale, ran into that drive label issue, replaced the drive with the drive it could see (which i knew belonged to the pool) and set up SMB share on both datasets after noticing the permissions thing.
So i clearly am missing or not understanding something. Which is why i came here and asked what would be best for me, to proceed from this point.
OK, so let’s try to make it simple. From the info you have given I understand the following:
In core you had created one user named Jerren (which might have had the ID 1000 as core starts user accounts at 1000)
The other ID 989 must be from an app/jail (deducing from the dataset name iocage) which is managed by system. (Did you have plex or something like that on core?)
From the ACL, the 989 user was given full permission. but this is not a big issue until you figure out/recollect what supporting app you had setup in core. Unless you need that service again, you are fine and need not bother about 989.
Now on the new system, let’s start step by step :
Again for simplicity you can create a new user on Scale with name Jerren (and if that is the first user it will have ID 3000. but you need not worry a lot about this id too much.)
Now you can go back to the dataset and change the owner to Jerren.
In case you are able to recollect which app you were using in iocage setup, you can try to setup the same on Scale and that should take care of old 989 user permission. (note, the new app need not be using the same username/id)
Ideally this should be enough to start with and no need to transfer the files etc.
I tried to make a simulated set of screenshots, for your better understanding. Please see the images below hope it helps.
What you are describing is having to redo all permissions on the pool. It needs to be done recursively. You are also losing information about group memberships and gids.
This simple fact of the matter is you are using local user and group accounts and don’t want to have to redo all of your permissions, then you will need use your old configuration file to migrate.
If you want consistency for accounts between multiple servers you must use AD / LDAP.
Alright, thank you very much for being so helpfull and going above and beyond with the screenshots!
I just did those permissions on Marine as you outlined but before i try to change the ones on Tiger, i noticed something. Does it matter that Marine is in Unix permissions and Tiger has NFSv4 permissions? While the pool itself still has Unix permissions?
Also yes i had Emby on my Core install which i will use again here but as far as i understand it, Apps use the user Apps in Scale so i’ll remove user 989 from Tiger dataset and just use the builtin Apps user from Scale.
@awalkerix From the original question, I feel OP is a basic user and tried to explain as simple as possible. Don’t you feel AD/LDAP etc will be a bit complicated for a user to understand in this scenario? (Especially when he seems already confused with local user ID and username)
