Users, groups, and sudo · General · guides.freberg.guru

Linux is multi-user from the ground up. Even on a laptop only you ever touch, the system is quietly juggling dozens of accounts: yours, a special all-powerful one called root, and a crowd of behind-the-scenes accounts that web servers, printers, and other services run as. Every file on the disk is owned by a user and a group, and that ownership is what decides who may read, change, or run it.

This guide covers two related skills: managing the users and groups on a system — creating them, putting them in the right groups, removing them — and granting administrative rights safely. The golden rule for that second part is simple: you do not log in as root and live there. You stay your ordinary self and borrow root's powers, one command at a time, with sudo. This guide explains why, and how to set it up without locking yourself out.

This is a companion to the Permissions, ownership, and the sticky bit guide — that one explains how the read/write/execute bits work once a file has an owner; this one is about the users and groups that do the owning. Every tool here is free and open source and already installed: account management comes from shadow-utils (the useradd/usermod/passwd family, GPL), and sudo itself is BSD-licensed. Nothing on this page is paid, proprietary, or cloud.

Who am I, and what accounts exist?

Before changing anything, learn to look. Four commands tell you who you are and what is already on the system, and none of them changes a thing.

# print just your username
whoami
# print your user id, group id, and every group you belong to
id
# list the groups you are a member of
groups

The output of id is the one to understand. It looks like this:

uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),44(video),108(docker)

Read it left to right. The uid (user id) is your account's number — humans usually start at 1000. The gid is your primary group. The groups= list is every group you are in, primary and otherwise; here alice is also in sudo (so she can run admin commands), video, and docker. We come back to what those mean below.

To see all the accounts on the system — not just yours — use getent, which reads the same account databases the system itself uses:

# list every user account on the system
getent passwd
# list every group
getent group
# look up one specific user or group
getent passwd alice
getent group sudo

Tip: scrolling through getent passwd you will see far more accounts than there are people — root, daemon, www-data, systemd-network, and so on. Those are system accounts: services run as their own low-privilege user so that a compromised web server cannot read your mail. They are not logins for people.

UID and GID ranges: system versus human

Account numbers are carved into ranges so the system can tell people apart from services:

UID 0 is root — the superuser, who may do absolutely anything. It is the one account whose number, not name, grants the power: any account with uid 0 is root.
1 to 999 are reserved for system / service accounts (the exact ceiling is set by /etc/login.defs, but 999 is the common default).
1000 and up are ordinary human accounts. Your first account is almost always 1000, the next 1001, and so on.

This is why creating a normal user and creating a service account are slightly different jobs — the tools below have a --system switch precisely to land an account in the low range.

Creating a user

There are two layers of tool for this, and knowing which you are using saves a lot of confusion.

The friendly way: adduser (Debian, Mint, Ubuntu)

On Debian-family systems there is a high-level, interactive helper called adduser. It is a friendly wrapper that does everything for you: it creates the account, makes a home directory, sets up a matching personal group, and then prompts you for a password and a few optional details.

# Debian / Mint / Ubuntu only
sudo adduser alice

Answer its questions and you are done — a complete, ready-to-log-in account. This is the recommended route whenever it is available, because it leaves nothing half-configured.

Tip: do not confuse adduser (the friendly interactive wrapper) with useradd (the low-level tool below). On Arch and Fedora adduser usually does not exist at all, which is exactly why it is worth knowing both.

The universal way: useradd (every distribution)

useradd is the low-level tool that exists on every Linux system. It does exactly what you tell it and nothing more — notably, on its own it does not create a home directory or set a password, which surprises newcomers. So you pass a couple of flags and then set the password as a second step:

# -m makes the home directory, -s sets the login shell
sudo useradd -m -s /bin/bash alice
# then set a password (you will be prompted for it twice)
sudo passwd alice

The flags worth knowing:

-m — make the home directory (/home/alice) and populate it from /etc/skel. Without this the user has nowhere to put files.
-s /bin/bash — set the login shell. Common choices are /bin/bash or /usr/bin/zsh; use /usr/sbin/nologin for an account that should never log in.
-G group1,group2 — add the user to one or more supplementary Groups at creation time (for example -G sudo to make them an admin straight away).
-c "Alice Smith" — a comment, traditionally the person's full name.
--system — create a service account in the low UID range, with no home and no expiry, for software rather than a person.

So a fully specified human account in one line looks like this:

sudo useradd -m -s /bin/bash -c "Alice Smith" -G sudo alice
sudo passwd alice

Modifying a user

Once an account exists, usermod changes it. The single most important — and most dangerous — thing it does is manage group membership, so read the next warning carefully.

Adding a user to a group (and the -a trap)

To add someone to a group, use -aG: -G says "set supplementary groups", and -a says "append, do not replace":

# add alice to the docker group, keeping all her existing groups
sudo usermod -aG docker alice

Warning: never omit the -a. Running usermod -G docker alice (without the a) replaces every supplementary group alice has with just docker — silently dropping her from sudo, video, and everything else. People lock themselves out of admin rights this way. The mantra is: always -aG, never bare -G.

Group changes do not apply to sessions that are already running — see Groups below for how to pick them up without a full logout.

Other common changes

# change the login shell
sudo usermod -s /usr/bin/zsh alice
# rename the account login (does NOT move the home directory by itself)
sudo usermod -l newname oldname
# change the primary group
sudo usermod -g developers alice

Passwords and account locking are handled by passwd:

# set or change a user's password
sudo passwd alice
# LOCK the account (disables password login; the user cannot sign in)
sudo passwd -l alice
# UNLOCK it again
sudo passwd -u alice

Locking is the polite way to disable an account without deleting it — for someone on leave, say. To make an account stop working on a date, use chage (the password-ageing tool) to set an expiry:

# expire the account on a fixed date (after this, no login)
sudo chage -E 2026-12-31 alice
# show the current ageing / expiry settings
sudo chage -l alice

Deleting a user

To remove an account, use userdel. By default it deletes the account but leaves the person's home directory behind; the -r flag removes their home directory and mail spool too:

# delete the account AND its home directory and mail
sudo userdel -r alice

Warning: -r deletes /home/alice and everything in it permanently. If there is any chance you will want those files, copy them off first. Note too that any files the user owned elsewhere on the system are not removed — they are simply left owned by a now-unused UID, which can later be reused by a new account; hunt them down with find / -uid <number> if it matters.

Groups

A group is just a named bundle of users, used to share access. Instead of granting permission to ten people one by one, you grant it to a group and put the ten people in it. Every user has exactly one primary group (the one new files they create are owned by) and any number of supplementary groups (extra memberships that grant additional access).

Creating and deleting groups

# create a new group
sudo groupadd developers
# delete a group (it must not be anyone's primary group)
sudo groupdel developers
# add or remove members with gpasswd
# add alice to the developers group
sudo gpasswd -a alice developers
# remove alice from the developers group
sudo gpasswd -d alice developers

Both gpasswd -a and usermod -aG add a user to a group; either is fine. gpasswd is the natural choice when you are thinking "manage this group", and usermod -aG when you are thinking "manage this user".

Group changes take effect at next login

Here is the gotcha that confuses everyone once: when you add yourself to a group, your current shell session does not know about it yet. Group membership is read at login, so you usually have to log out and back in for the change to take effect. To test it sooner without a full logout, start a fresh shell that re-reads your groups with newgrp:

# start a new shell with the freshly granted group active
newgrp docker
# confirm the group is now listed
id

The groups worth knowing

A handful of groups grant specific, useful powers. Membership in these is how a normal user is allowed to do otherwise-privileged things:

sudo (Debian/Mint/Ubuntu) or wheel (Arch/Manjaro/Fedora) — the admin group: members may use sudo to run commands as root. This is the important one, covered next.
video, audio — access to the GPU / camera and sound hardware.
disk — direct read/write access to raw disk devices. Powerful and dangerous — effectively equivalent to root, since it can read any file on the disk. Add people to it sparingly.
docker — allowed to talk to the Docker daemon. Also effectively root-equivalent (a container can mount the host), so treat it like admin access.
plugdev — access to removable/pluggable devices (USB sticks, card readers) on desktop systems.

Using sudo properly

sudo ("superuser do") runs a single command with root's powers, after checking you are allowed to and asking for your own password. It then logs what you ran. This is why it beats logging in as root:

You stay yourself. Day to day you run as an unprivileged user, so a mistake or a malicious program only has your limited powers, not root's.
It is per-command and on purpose. You reach for root only for the one command that needs it, then drop straight back down.
It leaves a trail. Every sudo use is logged with who, when, and what — invaluable on a shared machine.
No shared root password. Several admins can each have sudo rights with their own passwords; nobody has to know root's password (which can stay unset).

Most of the time you just prefix the privileged command:

# run one command as root
sudo systemctl restart nginx

When you genuinely need an interactive root shell — say you are about to run many admin commands in a row — ask sudo for one rather than logging in as root:

# a full root login shell (loads root's environment) - prefer this
sudo -i
# a root shell that keeps your current environment
sudo -s

You may also see the older su ("substitute user"). su - switches you to root by asking for root's password (not yours) and gives a full login shell; su - alice switches to another user. On a sudo-based system you rarely need it — sudo -i does the same job with your own password and a log entry.

Granting someone admin rights

The clean way to make a user an administrator is to add them to the admin group — and which group that is depends on your distribution:

# Debian / Mint / Ubuntu - the admin group is "sudo"
sudo usermod -aG sudo alice

# Arch / Manjaro / Fedora - the admin group is "wheel"
sudo usermod -aG wheel alice

After this, alice logs out and back in, and she can use sudo. On a fresh Arch install you may first need to enable the wheel group in the sudo rules (it ships commented out) — the next section shows exactly how, safely.

Tip: adding someone to sudo/wheel is almost always what you want instead of writing a custom rule. The group line is already in the sudoers file by default, so membership is all it takes. Reach for hand-written rules only when you need to grant something narrower than full admin.

Tip: not sure which one your system uses? It is whichever exists — check with getent group sudo and getent group wheel (the admin group is the one that returns a line). The definitive answer is whichever %sudo or %wheel rule is present and uncommented in /etc/sudoers: that is the group whose membership actually grants root. Debian, Ubuntu, and Mint use sudo; Arch, Manjaro, and Fedora use wheel.

Editing sudo rules safely

The rules that decide who may run what live in /etc/sudoers and in drop-in files under /etc/sudoers.d/. There is one iron law for editing them.

Warning: always edit sudo rules with visudo, never with a plain text editor. visudo locks the file against simultaneous edits and — crucially — syntax-checks your changes before saving. A single typo in /etc/sudoers can make sudo refuse to run at all, and if root has no password (the norm on Ubuntu/Mint) you are then locked out of admin entirely, with no way back short of booting from rescue media. visudo catches the mistake and lets you fix it before it bites.

# open the main sudoers file safely (syntax-checked on save)
sudo visudo

Better still, do not touch the main file at all. The recommended practice is to add your rules as a small separate file in /etc/sudoers.d/, which keeps your changes apart from the distribution's defaults and survives upgrades cleanly. Point visudo at the new file with -f so it is still syntax-checked:

# create/edit a drop-in rule file, syntax-checked just like the main file
sudo visudo -f /etc/sudoers.d/alice

Inside that file, the rule format is who where = (as-whom) what. A few practical examples:

# Full admin: alice may run any command, as any user, on any host
alice ALL=(ALL:ALL) ALL

# The same, but for everyone in the wheel group (note the % means "group")
%wheel ALL=(ALL:ALL) ALL

# Restricted: bob may run ONLY these two commands as root
bob ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/journalctl

# Passwordless for ONE specific command (see the caution below)
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

The leading % marks a group rather than a single user, which is exactly how the default %sudo / %wheel lines work. The command-restricted form is the right tool when you want to let someone restart one service without handing them the whole machine.

Warning: NOPASSWD lets a command run with no password prompt — convenient for scripts and automation, but it removes a safety check. Scope it as tightly as you can: a single, specific command (with its full path), never NOPASSWD: ALL. Granting passwordless access to a command that can spawn a shell or write arbitrary files (an editor, find, tar, a package manager) effectively hands over full root with no prompt at all.

Tip: a safety net if you are nervous about locking yourself out — keep a second terminal already logged in with a working sudo open while you edit. If a change breaks sudo, that still-authenticated session can fix it. visudo makes this rarely necessary, but it is a good habit on a remote server.

The files behind it all

Everything above is a friendly front-end to three plain-text files. You should know what they hold, but the rule is read to understand, never hand-edit — use the tools (useradd, passwd, visudo), which keep the files consistent and locked while writing.

/etc/passwd — the account list

Despite the name, this file holds no passwords any more. It is world-readable and lists every account, one per line, with seven colon-separated fields:

alice:x:1000:1000:Alice Smith:/home/alice:/bin/bash

Left to right: username · password placeholder (the x means "the real hash lives in /etc/shadow") · UID · primary GID · comment (the full name from -c) · home directory · login shell.

/etc/shadow — the password hashes (root-only)

The actual password hashes live here, in a file readable only by root. That separation is the whole point: /etc/passwd can stay world-readable for the username lookups programs constantly need, while the secret hashes sit in a file no ordinary user can read, so nobody can grab them to crack offline. Its fields include the username, the hashed password, and password-ageing data (last change, minimum/maximum age, expiry).

Warning: never loosen the permissions on /etc/shadow and never edit it by hand. If it must change, use passwd, chage, or (if you truly know what you are doing) vipw -s, which locks the file properly. A world-readable /etc/shadow is a serious security hole.

/etc/group — the group list

World-readable, one group per line, four colon-separated fields:

docker:x:108:alice,bob

Left to right: group name · password placeholder (group passwords are rare) · GID · a comma-separated member list of users who have this as a supplementary group. (Users who have it as their primary group are recorded in /etc/passwd instead, so do not be surprised when someone is "in" a group without appearing on this line.)

Tip: to edit these files when you really must, the shadow-utils suite provides locking-aware editors: vipw for /etc/passwd, vipw -s for /etc/shadow, and vigr for /etc/group. They are the visudo of the account files — but in day-to-day use you should reach for useradd/usermod/gpasswd/passwd and leave the raw files alone.

Quick reference

whoami · id · groups — who am I and what groups am I in.
getent passwd / getent group — list all accounts / groups.
sudo adduser alice — friendly interactive create (Debian/Mint/Ubuntu).
sudo useradd -m -s /bin/bash alice && sudo passwd alice — universal create + set password.
sudo usermod -aG group alice — add to a group. Always -aG, never bare -G.
sudo passwd -l alice / -u — lock / unlock an account.
sudo userdel -r alice — delete the account and its home directory.
sudo groupadd / groupdel · sudo gpasswd -a/-d user group — manage groups (effective at next login, or newgrp).
sudo usermod -aG sudo alice (Debian) or -aG wheel alice (Arch/Fedora) — grant admin.
sudo visudo — edit sudo rules safely (syntax-checked); sudo visudo -f /etc/sudoers.d/alice for a drop-in.
Rule shape: alice ALL=(ALL:ALL) ALL · scope NOPASSWD to one specific command, never ALL.
Files: /etc/passwd (accounts), /etc/shadow (hashes, root-only), /etc/group — read to understand, edit via the tools.