I’m getting started with TrueNAS SCALE, and also with really digging into the details of user/group permissions and ACLs, so I’ve decided to climb two rather steep hills at the same time.
I’ve got what I hope is a confusing to me but otherwise simple question.
I’m looking to set up CIFS/SAMBA and NFS shares.
I"ve seen two approaches to setting up users and groups in the tutorials I’ve reviewed in my research:
I’d really like to have a better understanding of this before I start building datasets and shares, so I don’t create issues for myself later that someone who knows what they’re doing would have avoided. Thanks for your help.
In either case, set up groups to use for groups-based permissions. But then I’ve got two choices for how to set up the users:
Set up a User Bob, whose primary group is Bob, and then assign Secondary Groups (e.g., Proxmox Users). Use the secondary groups to set permissions for shares.
Set up a User Bob, do not create a new Primary Group Bob, and assign a Primary Group and secondary Groups as necessary to manage permissions.
I should note that I saw method (1) used in a SCALE tutorial (linux), and method (2) used in a CORE tutorial (BSD).
So … which approach is more … I hesitate to say correct. Which approach is less likely to cause me issues later? Which is used by people who actually get paid to do this?
Are there any implications for actual functionality? Or is it purely a style thing? (Granted, I’m not deep enough into Linux yet to really understand why User Bob has a Group Bob. I signed up for a class…)
I suspect that the permissions system works somewhat differently in BSD vs. Linux and that might account for the difference, but I’m just guessing at this point.
This is how I approached the organization of it all.
Organize users as it makes sense as users. So round them into the appropriate groups depending on what files they might need to access now or in the future.
Then create the shares and use the provided ACLs to restrict or expand the access to a given share.
Share’s ACL are way harder to work on so they should not be changed after the fact to avoid losing access to your data. When modifying users is much more difficult to make a mess, but it’s still possible if you delete a user and create it again from scratch because UID and GID will change.
Example:
Create the user Bob. What’s Bob purpose? What’s his domain? Bob’s role is being an admin to a Proxmox server. Bob is part of the proxmox group.
However, if Bob needs to manage it’s own files first and is also a Proxmox admin, creating a group for Bob makes sense.
Yes and no. It’s both a style thing but also a key to keep everything properly organized.
Functionality wise you can achieve the same results, but it’s gonna be a bit messy because adding too many groups and permissions to a single user when not needed gets messy really quickly. Other than being potentially dangerous.
I hope to learn something too or have confirmations on my ideas. Cheers!
Add users to groups
Assign ACL permissions per group
Add and remove users to group as needed
Exercise:
Share: A B C
Users: 1 2 3
Share / Access
A - 1 2 3
B - 1 2
C - 1 3
If 1 is a data administrator, create group and assign accordingly
else
create groups to divy up shares assigning each user to each group based on access levels
For the love of God, do not nest shares with different ACL’s
Unix does not respect them and Windows gets confused with inheritence
Thank you both. This is super-helpful and I feel like I’m 95 percent of the way to being ready to do this.
One point is still sticking a bit: when does a user need to be able to “manage their own data?” in the context of this discussion? Most/all of the users I’m concerned about just need to be able to read/write into shared folders, and I’m not sure that is what is being referred to here.
By the same token, who is the “data administrator?”
I mean, obviously, that’s me, but what does the term mean? What actions does it comver?
I think my newness to all this and lack of familiarity with some of the terminology is biting me here. For context:
This is a home server/homelab environment.
I am the only human that has access to TrueNAS’ admin system/the actual full filesystem/dataset, users, groups, and share settings (either through the web GUI or CLI).
I’m the only one in the house that is even aware of how anything on the network actually works. I set it up, and people do things until they break it. Then I fix it.
Other users will either be entities/programs (like Proxmox) that use the NAS as a data store, or humans for whom I set up a share on their machines. That is, the humans (and the entities) will just see a place they can store things.
I’d noticed that I could do [1], but instictively realized that was too complicated and confusing to be useful to me. I assume it’s possible because some Elite Nerd Wizard knows how to do it safely in a way that brings … some sort of benefit. Thanks for the warning, though.
As to [2], I chuckled a bit at this, as for some reason one of the places I used to work decided to move from a Unix-based file server infrastructure to a Windows Server-based one (?!).
I was locked out of my share at work (and all my files) for a good two days because the inherited permissions confused the Windows fileserver into a non-working state. But just for me.
In security compliant environments you have (at least) 2 types of admins:
Systems Administrators - no data access, perform system maintenance
Data Administrators - full data access, no system level administrator access
Below that is “Managers” who have restricted Data access, but can assign access to the data they manage to their subordinates.
As for shares and groups:
Let’s say you have shares:
video_archive
video_current
video_staged
video_raw
groups:
Employees
Editors
Photographers
Employees would have:
video_archive - read
video_current - read
Photographer Bob would be a member of:
Employees
Photographers
and subsequently have the following ACL’s:
video_archive - read
video_current - read
video_raw - read & write
If Bob gets fired, he is removed from the ACL groups and his account disabled. This does not change the share ACL, just his ability to authenticate.
I approach the answer to this question from the UNIX side, on the system itself. A share, to me, it’s not the same as a user working on their own files on the base system. This option is afforded by Truenas due to it’s ability to create users with no home folder on the system and no access to the shell.
So UNIX user != share user
Responsible of the safety of the data, can access all of them on the system and enforces policies. By this token, in my own environment, root covers these roles.
I think this is everything I need to get going and not make any mistakes that I’ll regret (because I can’t easily fix them) later.
I’m the only system admin, for which the “admin” account already exists. (Root is disabled – or at least, I haven’t set a password for it so it’s impossible to log into directly without logging into admin and sudo’ing into it.
I’m also the only human data admin.
So, most/almost all of the users I’m going to set up aren’t going to need UNIX accounts on the system: they’ll exist to access fileshares.
Veering off topic a bit, I’m not sure whether I should bother setting up a new user with administrator privileges and stop using the default admin user, so long as my default admin user has a strong password. If I were in any organization or team, yes. But I’m the only human who is meant to have access to this thing or even knows it exists/where it is in the real world.
The only benefit I can think of to setting up a “johntdavis” UNIX user with admin powers is that I’m a bit more comfortable uploading files or doing other CLI things in a home directory that the “admin” account doesn’t control/expect to be in a certain state. I’m not sure how much of a concern that actually is.
Generally the Global Admin / root account has remote access disabled with a password set as a break glass on-prem option in the event of disaster recovery.
All admin accounts are subsequently created and destroyed with each changing of the guard.
We regularly set a DataOwner group to ease transitions during acquisitions and mergers.
I personally prefer to only grant permissions to groups, and users are put into groups according to their needs. quite like the interfaces in programming .
Checking back in. I’ve managed to confuse myself a little bit and wanted a bit more advice so I don’t have to redo this after doing it wrong.
I want to set up some basic SMB/NFS file shares for human users (e.g., Peter, Paul, Mary, and ShareAdmin who can see everything, who just need a shared folder to put stuff in.
At first, it made sense to me to try to avoid flattening my dataset structure, and have a parent “UserShares” dataset with master settings for things like recordsize, etc., with child datasets for Peter, Paul, and Mary.
But Peter, Paul, and Mary would all need read/write access to their own datasets (via shares) underneath UserShares, and no access at all to anyone else’s datasets.
But since apparently best-practice is not to modify the permissions/ownership of UserShares’ child datasets, I find myself a bit stuck on what to do here.
I feel like I’m either misunderstanding what I read as best practice, or I’m missing something obvious. This also feels like something that will make a lot more sense once I’ve seen an example and done it once or twice.
Maybe we didn’t explain properly so you were led to think that. What we, or at least I, meant to say is that you should modify ACL permissions as little as possible but in this case is inevitable. Also you need to “concentrically” reduce permissions starting from the parent dataset.
So for each of your users you’re gonna have them be the owner of the dataset.
How I would do that in your situation is create the users you need, do not create home folders for any of them, no group for Peter, Paul and Mary, create the ShareAdmin group for the ShareAdmin user. Put Peter, Paul and Mary in a group for them (family, friends, users, whatever fits you).
When creating the ACL for the shares the parent share needs full control by ShareAdmin, so set it as “full control” under user and group. For each child dataset set the appropriate user as the owner and the group ShareAdmin as the group owner of the files that will be in their shares.
Thanks for these clarifications. Y’all are explaining it great, but this is my first real exposure to ACLs and also the first application where I’ve needed to consider group-based permissions, so I think I’m overthinking the wrong things and getting snagged on the sort of details you only learn by doing.
Concentric reduction is a great metaphor. That clears it up quite a bit. It definitely makes sense that you’d not want to go in the opposite direction: the child having more permissions than the parent seems … a bad idea (assuming TrueNAS even lets you do that, but these datasets are created as belonging to root, and in my experience Linux lets the root user be as stupid as they desire ).
So, to make sure I understand:
Create user ShareAdmin with their own group, ShareAdmin (Does this user need a home folder? I think not, but I also don’t think it would hurt anything if they had one?)
Create users Peter, Paul, and Mary without their own primary groups (“no group for Peter, Paul and Mary”). Put them all in a single primary group (“family, friends, users,” etc.)
ACL on Parent: Full Control to ShareAdmin user/group.
ACL on Children: Full Control to Owner/user, group is ShareAdmin.
Just to confirm, with this setup Peter, Paul, and Mary can’t see or modify each other’s datasets?
(I know there are access restrictions built into SMB too, but I’m not sure where the ACL stops and the SMB access permissions need to be adjusted.)
And from my understanding, as the owner of the parent, ShareAdmin can see and read/write everything.
I tend to fall into this same trap so try to get some things done and see what works. That’s pretty much how I did it too and it worked. Also testing out permissions, shares and volumes it’s not a big deal.
You got it and yeah, Peter, Paul and Mary will not have access to each other files meanwhile ShareAdmin will have access to all their files.
.