Managing Users & Groups

Every action on a Linux server happens as some user — a named account that owns files and runs programs. Linux also has groups, which are simply collections of users that let you grant the same permissions to many people at once. As a DevOps engineer you will constantly create accounts for teammates, service software, and automation, so knowing exactly how users and groups work (and which files store them) is one of the first skills to master. This page covers creating, changing, and deleting users and groups on Ubuntu, and explains the plain-text files behind it all.

Why users and groups matter

On a server you almost never log in as the all-powerful root user for day-to-day work. Instead you create normal users with limited rights and grant them extra power only when needed (see Sudo and root). This limits the damage a mistake or an attacker can do. Groups make permissions manageable: instead of giving ten people access to a folder one by one, you put them in a group and give the group access once.

There are two kinds of accounts you will meet:

Account type	Purpose	Example
Human (login) user	A real person who logs in via SSH	deploy, alice
System (service) user	Runs a background program, cannot log in	www-data, postgres

The files behind it all

User and group data live in plain text files. You can read them, but you should change them with the proper commands rather than editing them by hand.

/etc/passwd

/etc/passwd lists every account on the system, one per line. Despite the name, it does not store passwords (those moved to /etc/shadow long ago). View it:

grep deploy /etc/passwd

Output:

deploy:x:1001:1001:Deploy User:/home/deploy:/bin/bash

Each line has seven colon-separated fields: username, an x (password is in /etc/shadow), UID (user ID number), GID (primary group ID), a comment/full name, the home directory, and the login shell. A user whose shell is /usr/sbin/nologin cannot log in interactively — that is how service accounts are locked down.

/etc/group

/etc/group defines groups and which users belong to them:

grep sudo /etc/group

Output:

sudo:x:27:deploy,alice

The fields are group name, an x placeholder, the GID, and a comma-separated list of secondary members. A user’s primary group comes from the GID field in /etc/passwd; secondary groups are listed here in /etc/group.

Editing /etc/passwd or /etc/group by hand risks a typo that locks everyone out. Use the commands below — or vipw/vigr, which lock the files and check syntax before saving.

adduser vs useradd

Ubuntu ships two ways to create a user, and the difference trips up newcomers constantly.

Command	What it is	Behaviour
adduser	A friendly Perl script (Debian/Ubuntu)	Interactive: creates the home directory, copies skeleton files, prompts for a password and details
useradd	The low-level core utility	Non-interactive: creates only what you explicitly ask for; no home dir or password unless you add flags

When to use which: use adduser for human accounts you set up by hand — it does the right thing with one command. Use useradd in scripts and automation where you need predictable, non-interactive behaviour.

Creating a user with adduser (recommended for humans)

sudo adduser deploy

Output:

Adding user `deploy' ...
Adding new group `deploy' (1001) ...
Adding new user `deploy' (1001) with group `deploy' ...
Creating home directory `/home/deploy' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for deploy
Enter the new value, or press ENTER for the default
	Full Name []: Deploy User
...
Is the information correct? [Y/n] Y

It creates /home/deploy, a matching primary group, and prompts for a password.

Creating a user with useradd (for scripts)

sudo useradd --create-home --shell /bin/bash deploy
sudo passwd deploy

The --create-home (-m) flag makes the home directory and --shell sets the login shell. Without -m there is no home directory at all. You then set a password with passwd.

To create a service account that cannot log in:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

--system gives it a low UID and --shell /usr/sbin/nologin blocks interactive login — ideal for accounts that only run a systemd service.

Adding a user to a group with usermod

The most common task is granting an existing user extra rights by adding them to a group. Use usermod with -aG:

sudo usermod -aG docker deploy

The flags matter: -G sets secondary groups and -a means append. Always include -a — usermod -G docker deploy replaces all of the user’s secondary groups, silently removing them from every other group.

Group changes only take effect in a new login session. The user must log out and back in (or run newgrp docker) before the new membership is active.

Granting sudo (admin) rights

On Ubuntu, members of the sudo group can run commands as root. To make deploy an administrator:

sudo usermod -aG sudo deploy

Verify it after the user logs back in:

groups deploy

Output:

deploy : deploy sudo docker

For fine-grained control over what a user can do as root, see Managing the sudoers file.

Modifying and inspecting users

# Show the groups a user belongs to
groups deploy

# Show UID, GID, and all groups with numbers
id deploy

# Change a user's login shell
sudo usermod --shell /bin/bash deploy

# Lock (disable) an account without deleting it
sudo usermod --lock deploy

# Unlock it again
sudo usermod --unlock deploy

id deploy is the quickest way to confirm exactly what an account can do:

Output:

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

Creating and managing groups

# Create a new group
sudo addgroup developers

# Add a user to it
sudo usermod -aG developers alice

# Remove a user from a group
sudo deluser alice developers

# Delete a group entirely
sudo delgroup developers

addgroup/delgroup are the friendly Ubuntu wrappers; groupadd/groupdel are the low-level equivalents, just like adduser vs useradd.

Deleting a user

To remove a user but keep their files:

sudo deluser deploy

To remove the user and their home directory and mail spool:

sudo deluser --remove-home deploy

Output:

Looking for files to backup/remove ...
Removing user `deploy' ...
Warning: group `deploy' has no more members.
Done.

Before deleting an account, check for files it owns elsewhere on the system with sudo find / -user deploy 2>/dev/null. Deleting the user leaves those files owned by an orphaned UID number.

Best Practices

• Use adduser for people and useradd --system for service accounts — never run apps as root.
• Always pass -a with usermod -G so you append groups instead of wiping existing memberships.
• Give human admins access via the sudo group rather than sharing the root password.
• Set service accounts to /usr/sbin/nologin so they cannot be used for interactive login.
• Never edit /etc/passwd or /etc/group by hand; use the commands or vipw/vigr which validate changes.
• Remind users to log out and back in after a group change, or it will appear to “not work”.
• Audit accounts periodically: getent passwd lists everyone, and sudo find / -user <name> finds their files before cleanup.

Related Topics

• Sudo and root
• Managing the sudoers file
• Viewing logs with journalctl
• systemd services
• System information