Linux Users and Groups: Who's Allowed to Do What on a Server

A Linux server is almost never used by one person doing one thing. There’s the human who set it up, the program that runs the website, maybe a background job that takes backups at 3 a.m., and a couple of teammates who occasionally log in to check on things. Linux keeps all of that orderly with a deceptively simple idea: every action on the system belongs to someone, and that someone is a user. Group those users together and you get a group. From there, the whole question of “who’s allowed to do what” falls neatly into place.

If you’ve ever seen permission denied on a server and weren’t sure why, this is the missing piece. Users and groups are the identity layer of Linux — they decide who you are, and that, in turn, decides what you’re allowed to touch. Let’s build the whole picture from the ground up.

What a user actually is

A user in Linux is just an account — an identity the system recognizes. When you do anything on the machine (read a file, run a program, open a network connection), you do it as some user, and the system checks that user’s rights before letting it happen.

Here’s the part beginners often miss: not every user is a human. Linux uses user accounts for programs too. The web server software runs as a user (often one literally named www-data or nginx). A database runs as its own user. These are called system users or service accounts, and they exist so that each program has its own limited identity instead of everything running with full power. If the web server gets compromised, the damage is fenced in by what that user is allowed to do.

Every user has a few key properties:

• A username — the human-readable name, like jane or www-data.
• A UID (user ID) — a number the kernel actually uses internally. The name is for humans; the number is for the machine.
• A home directory — usually /home/username, a private folder that belongs to that user.
• A login shell — the program that runs when they log in (often /bin/bash). Service accounts are frequently given a “no login” shell on purpose, so nobody can log in as them.

You can see who you currently are at any time:

whoami        # prints your username
id            # prints your UID, your group, and all groups you belong to

A typical id output looks like this:

uid=1001(jane) gid=1001(jane) groups=1001(jane),27(sudo),998(docker)

That single line says: you’re jane (UID 1001), your main group is also jane, and you additionally belong to the sudo and docker groups. Hold that thought — those extra groups are where a lot of your power comes from.

The special user: root

One user stands apart from all the others: root, also called the superuser. Root has UID 0 and is allowed to do essentially anything — read any file, kill any process, change any setting, delete the entire system if it wanted to. There are no permission checks for root; the rules simply don’t apply.

That power is exactly why you should treat root with respect. A normal user who fat-fingers a command usually just gets permission denied and nothing bad happens. Root who fat-fingers the same command can wipe out the machine. So the modern best practice is: don’t log in as root for everyday work. Log in as a normal user, and borrow root’s power only for the specific moments you need it.

What a group is, and why it exists

A group is a named collection of users. That’s the whole concept — but it solves a very real problem.

Imagine five developers all need to read and write the files for a project. Without groups, you’d have to grant each person access to each file individually, and update every file every time someone joins or leaves the team. Painful and error-prone. With groups, you create one group — say, developers — put all five people in it, and grant the group access to the project files. Add a sixth teammate? Drop them into the group and they instantly have access. Remove someone? Take them out of the group. The files never have to change.

Groups come in two flavors, and the difference trips people up at first:

• Primary group — every user has exactly one. When that user creates a new file, the file is owned by this group by default. It’s usually a personal group with the same name as the user (jane is in group jane).
• Secondary groups — any number, optional. These are the “you also belong to this team” memberships. The sudo, docker, and developers groups in our earlier example are secondary groups. They grant extra access without changing your primary identity.

   GROUP: developers
   ┌───────────────────────────────┐
   │   jane     john     alex      │
   │    │        │        │        │
   │    └────────┴────────┘        │
   │   all three can read/write    │
   │   files owned by this group   │
   └───────────────────────────────┘

This is the same identity system that the Linux file system leans on to decide who owns what. Every file records an owning user and an owning group, and Linux checks both against you when you try to open it.

Creating and managing users

Creating accounts is something you’ll do on almost any server you set up. The commands below are the standard, vendor-neutral ones found on essentially every Linux distribution. Most of them need root power, so you’ll usually prefix them with sudo (we’ll explain sudo in a moment).

Create a new user, complete with a home directory:

sudo useradd -m -s /bin/bash jane    # -m makes a home dir, -s sets the login shell
sudo passwd jane                      # set (or reset) their password

Some distributions also offer a friendlier adduser script that asks you questions interactively and sets up the home directory for you. Both end up creating the same kind of account.

Delete a user when they no longer need access:

sudo userdel jane            # removes the account, keeps their home folder
sudo userdel -r jane         # removes the account AND their home folder

Lock an account without deleting it — useful when someone’s away or you’re not sure yet:

sudo usermod -L jane         # lock (disable login)
sudo usermod -U jane         # unlock

The real list of every user on the system lives in a plain text file, /etc/passwd. Despite the name, it doesn’t hold passwords anymore — those are hashed and kept in /etc/shadow, which only root can read. You can peek at the user list any time:

cat /etc/passwd

Each line describes one account: username, a UID, a primary group ID, the home directory, and the login shell, separated by colons.

Creating and managing groups

Groups have their own small set of commands, mirroring the user ones:

sudo groupadd developers           # create a group
sudo groupdel developers           # delete a group

The key everyday action is adding a user to a group. The safe way is with -aG — the a matters, because it means append. Forget it and you’ll replace all of someone’s secondary groups instead of adding to them, which can quietly lock them out of things.

sudo usermod -aG developers jane   # add jane to "developers" (append — keep her other groups)

You can confirm the result with id jane, or list a group’s members and the wider group file:

groups jane                # which groups jane belongs to
getent group developers    # who is in the "developers" group

Switching users and borrowing power: su and sudo

Since you shouldn’t live as root, Linux gives you two ways to temporarily take on more power when a task genuinely needs it.

su (“substitute user”) switches you into another user’s identity for an entire session. Run su - and you become root (after entering root’s password); run su - john and you become John. You stay that user until you type exit. It’s an all-or-nothing switch.

sudo (“superuser do”) is the modern, safer approach, and the one you’ll reach for most. It lets an authorized user run a single command as root, asking for your own password (not root’s), and then drops you right back to your normal identity:

sudo apt update              # run just this one command as root
sudo systemctl restart nginx # and this one
ls /root                     # back to being yourself — this would now say "permission denied"

The advantages of sudo over logging in as root are real and worth understanding:

• Least privilege by default. You spend almost all your time as a limited user, and only step up for the exact command that needs it. The window for mistakes is tiny.
• An audit trail. Every sudo command is logged with who ran it and when. If three people administer a server, you can see exactly who did what.
• Granular control. You can grant someone permission to run only certain commands with sudo, rather than handing them the whole keys-to-the-kingdom root password.

Who’s allowed to use sudo is decided by membership in a group — commonly called sudo (Debian/Ubuntu family) or wheel (Red Hat family). Adding a user to that group is exactly how you give a new admin their powers:

sudo usermod -aG sudo jane   # jane can now use sudo

How users, groups, and access fit together

Step back and the whole system clicks into one picture. Linux ties everything together through identity:

1. Every file and folder has an owner — one user and one group.
2. Every running program runs as some user, inheriting that user’s rights.
3. When you try to do something, Linux checks your identity (your user, plus all your groups) against what the target allows.

So “can I edit this file?” really means: does my user own it, or am I in its group, and does that ownership level grant write access? Users and groups are the who; permissions are the what they’re allowed. They’re two halves of the same lock. Once you’re comfortable with the identity side here, the natural next step is the access side — the actual read, write, and execute rules attached to each file.

You’ll also notice how much of this depends on being comfortable at the prompt. If the commands above felt unfamiliar, it’s worth getting solid with the command line first, since every bit of user and group management happens there.

Wrapping up

Here’s the whole idea in one place:

• A user is an account — an identity Linux recognizes. Some users are humans; many are programs (service accounts) running with limited rights.
• root (UID 0) is the all-powerful superuser. Don’t use it for daily work — the risk is too high.
• A group is a named collection of users, so you can grant access to a whole team at once instead of person by person.
• Every user has one primary group (sets the group on files they create) and any number of secondary groups (extra team memberships, like sudo or developers).
• Manage accounts with useradd, userdel, usermod, passwd; manage groups with groupadd, groupdel, and usermod -aG (always append).
• Use sudo to borrow root’s power for one command at a time — safer than living as root, with a built-in audit trail and least-privilege by default.

Users and groups answer the question of who you are. The very next question — what that identity is allowed to do to each file — is decided by Linux file permissions, the read/write/execute rules that sit right on top of this identity layer. That’s where the picture becomes complete.