📖 Chapter 06 — Users & Groups
The accounts that authenticate against SMB and the groups that make permissions manageable.
Learning Objectives
- Create a user and a group in the TrueNAS web UI
- Explain the difference between the local admin and the root account
- Decide when to make a new user vs add someone to an existing group
- Configure a password policy that doesn't make your family hate you
Introduction
Users and groups are the identity layer of your NAS. Every dataset, every share, every permission eventually resolves to a question: who is asking, and what are they allowed to do?
The good news: for a family of four, you only need about 5 user accounts and 1-2 groups. This is the simplest part of the system. The bad news: getting the admin-vs-root distinction wrong can lock you out of your own NAS. So we'll cover that carefully.
The identity model
TrueNAS has three kinds of accounts:
- Built-in root — the superuser. Can do anything. Should never be used for everyday work.
- Local admin — a user account you create and grant administrative privileges to. This is what you use for NAS management.
- Local users — regular accounts for family members. No admin privileges.
TrueNAS lets you create multiple local admins. For a family NAS, one is enough. For a small business, you might want two (so one person can be on vacation without locking the other out).
Why "no root for everyday work"
Using root for daily tasks is the Unix equivalent of driving with the parking brake on. Root can do anything — including accidentally deleting the entire pool. A local admin can do most of what you need, but the system has guard rails. If a command is destructive and you're not root, the system will ask for confirmation or refuse outright.
More importantly: if you automate anything (scripts that mount shares, run apps, schedule tasks), those should use a service account or your local admin — never root. A bug in a root-run script can wipe the whole system. A bug in an admin-run script is contained.
Setting up the NAS with the root account, doing all the configuration as root, then trying to "lock it down later." By the time you want to lock it down, you don't know which files were created by root (and therefore are unreadable by anyone else) and which were created by your admin. Start with the right identity model from day one.
Users: who needs an account?
For TK's family, four user accounts:
- tk — the household administrator. Has full access to everything (including recovery access to all private datasets). Used for NAS management, project work, and TK's personal files.
- mimi — TK's spouse. Has access to shared family datasets and her own private dataset.
- lai — TK's sibling. Has access to shared family datasets and his own private dataset.
Note: there's no `admin` user separate from `tk`. The local admin role is a permission flag on the user account, not a separate account. `tk` is the admin; he's also a regular user with personal files.
When to add a new user
The rule: add a user when someone needs their own credentials and their own home directory.
Examples for a family:
- Each family member who logs in independently → user account
- A friend you want to give access to a specific shared folder → user account (more on this in Volume 2)
- An app that needs its own identity (Jellyfin, Immich) → user account with no login shell, used for the app's data permissions
Examples of when NOT to add a user:
- Someone who only needs read access to a single folder → give them a share with guest access (only if the network is trustworthy)
- Family members who are too young to have their own login → use a family-wide shared account (controversial but practical)
- Service accounts you don't actually need (see the next section)
Groups: how to manage permissions at scale
Imagine you have 4 family members and 6 shared datasets. Without groups, every permission rule looks like: "TK can read, Mimi can read, Lai can read, [future user] can read..." Every new user means editing every dataset.
With a group, the rule is: "Family can read." Add a new user? Add them to the Family group. Done.
The Family group
For TK's build, the conversation recommends exactly one group: Family. It contains all the family members (tk, mimi, lai). Every shared dataset (Family, Photos, Videos, Documents, Media) grants access to the Family group.
Private datasets are owned by individual users and explicitly do not grant access to the Family group. So the Family group gives you "easy on, easy off" for shared access.
Auxiliary groups for special access
Beyond the Family group, the conversation doesn't create any auxiliary groups in the v1 design. The pattern is:
- Default: you're in Family. Family datasets are readable.
- Exception: you own a private dataset. That dataset is owned by you, and the Family group is explicitly denied.
You might add a `Media` group later if you want some family members to have access to the Media/Active dataset but not others. But for v1, just Family is enough.
When to add a group
The rule: add a group when 3+ users need the same special access that others don't have.
For a family of 4, this rarely happens. For a small business with 10 employees in different roles, it's a daily occurrence. Match the complexity to the situation.
Home directories
When you create a user, TrueNAS can create a home directory for them (a per-user dataset the user owns). The conversation's recommendation: don't use the built-in home directory feature.
Why? Because the home directory convention puts user data in a path like /home/tk, which is fine for a Linux server but awkward for an SMB-shared NAS. For TK's build, the "private dataset" pattern (tank/Private/tk) is cleaner and more visible to the family.
Skip the home directory field when creating users. Put personal files in private datasets instead.
Password policies
The conversation's stance: make them strong enough to be real security, but not so painful that your family writes passwords on sticky notes and sticks them to the monitor.
Recommendations for a family NAS
- Minimum length: 12 characters (NIST's 2024 guidance). Not "uppercase + lowercase + digit + symbol" — just length.
- No forced rotation unless there's evidence of compromise. Forced rotation makes people use weaker passwords (Password1 → Password2 → Password3...).
- Use a password manager. Vaultwarden is the perfect answer (see Chapter 08). The NAS becomes the family's password vault; family members only need to remember one strong master password.
- Lockout after 5 failed attempts, 15 minutes. Stops casual brute force without locking you out for typos.
TrueNAS has a "Password Complexity" policy in the local user settings. Set it to "Normal" or higher, configure the minimum length, and move on. Don't over-engineer this.
Creating the first user
In the TrueNAS web UI: Credentials → Local Users → Add. The fields:
- Full Name — display name. Use real names so the family recognizes their own account.
- Username — short, lowercase, distinctive.
tk,mimi,lai. Not "Tom Smith" —tsmithor justtom. - Password — set a strong initial password. Communicate it through a secure channel (Signal, in person). Force change on first login if you want them to set their own.
- User ID — leave default. TrueNAS picks 1000+ for regular users, 1-999 for system accounts.
- Primary Group — set to
Family(or whatever you named your family group). - Home Directory — leave the auto-generated
/home/<username>but know that you won't use it. The real home is the private dataset. - Shell — for regular family users, set to
nologinor/usr/sbin/nologin. They don't need shell access; they only need SMB access. The admin user gets/bin/bashor similar for when SSH is needed. - Samba Authentication — enable. This is what lets the user authenticate to SMB.
- Administrative Privileges — enable only for the admin user (
tk).
That's a user. Save. Move on.
Engineering Note
Identity is the foundation of security. A perfect permission model is useless if anyone can log in as anyone. A user model is the bedrock: every other security decision builds on it.
For a family NAS, the user model is intentionally simple: a small number of named accounts, one group, no service accounts that you don't need. Complexity creeps in over time (when apps need their own accounts, when friends need access, when a child gets old enough for their own account). Add complexity only when a real need drives it.
Summary
Users are accounts. Groups are collections of users. The Family group makes shared permissions simple. Private datasets are owned by individual users, not by groups. Root is for emergencies, not for everyday work; your local admin user is for everyday work. Skip the home directory convention — use private datasets instead. Password policies: long, not rotated, stored in Vaultwarden.
Checklist
- ⬜ Create the `Family` group before creating any user accounts
- ⬜ Create the admin user (you) — set Samba auth on, admin privileges on, real shell
- ⬜ Create user accounts for each family member — set Samba auth on, admin privileges off, nologin shell
- ⬜ Test: log into SMB from your laptop as the admin user, verify you can see the shares
- ⬜ Test: log into SMB as a family member, verify you can see the shared shares but not private ones
Looking Ahead
Chapter 07 covers permissions — the rules that decide who can do what with each dataset. With users and groups in place, permissions become "which group or user gets read/write/deny on this dataset." The model is small but the implications are deep.