How to Manage Users and Groups in Linux: Practical Guide (2026)

How to manage users and groups in Linux comes down to five commands and a handful of files: useradd and usermod for accounts, userdel for removal, groupadd and gpasswd for groups, with the defaults stored in /etc/passwd, /etc/group and /etc/shadow. Every change should be verified before you move to the next one. Most broken servers come from a change nobody checked.

The walkthrough below uses Debian and Ubuntu, where sudo is the admin group and adduser wraps useradd with friendlier prompts. On RHEL-family systems the same core commands work, but the admin group is called wheel. I will note where the difference matters.

This reflects the tooling shipped with current Debian and Ubuntu releases as of 2026. Each step ends with a command that proves the change landed.

Table of Contents

• What You Need
• Step-by-Step: How to Manage Users and Groups in Linux
• Step 1: Inspect Existing Users and Groups
• Step 2: Create a New User Account
• Step 3: Create and Assign Groups
• Step 4: Edit Users and Group Membership
• Step 5: Control Login, Password, and sudo Access
• Step 6: Set File and Directory Permissions
• Step 7: Remove or Safely Disable an Account
• Common Mistakes When You Manage Users and Groups in Linux
• Frequently Asked Questions
• What is the difference between a Linux user and a Linux group?
• How do I add an existing user to a group in Linux?
• Should I edit /etc/passwd or /etc/group directly?
• How do I give a Linux user sudo access safely?
• What is the difference between deleting a user and locking their account?
• Conclusion

What You Need

You need root access or an account that already has sudo, a terminal, and the shadow-utils toolset. On Debian and Ubuntu that package is installed by default, so a fresh server already has everything below. Check before you start.

useradd --help 2>&1 | head -3
groupadd --help 2>&1 | head -3
which visudo adduser runuser

The core commands you will use:

• useradd, usermod, userdel, chage manage local user accounts and are in shadow-utils.
• groupadd, groupmod, groupdel, gpasswd manage groups, also from shadow-utils.
• passwd sets and changes passwords.
• adduser is the Debian and Ubuntu interactive wrapper around useradd, from the login package. It is not present on RHEL-family systems.
• visudo edits the sudoers file safely, checking syntax before it saves.
• id, groups, getent, lslogins read the account database back to you.

Four files hold the state. Know them before you change anything.

File	What it holds	Editable by hand?
/etc/passwd	Username, UID, primary GID, comment, home directory, login shell	Readable by all. Do not edit while processes are running.
/etc/shadow	Password hashes and password aging data	Never by hand. Mode 0640, root and shadow only.
/etc/group	Group name, GID, and the supplementary member list	Read-only in practice. Use gpasswd.
/etc/login.defs	Defaults for new accounts: UID_MIN, UID_MAX, CREATE_HOME, PASS_MAX_DAYS	Yes, this one is meant to be edited.

Defaults worth checking before onboarding anyone: CREATE_HOME controls whether useradd makes a home directory, and on some distributions it defaults to yes. On older RHEL releases it defaults to no, which is why an account created there sometimes has no home. Check it with grep CREATE_HOME /etc/login.defs.

Step-by-Step: How to Manage Users and Groups in Linux

Step 1: Inspect Existing Users and Groups

Never create an account before you know what already exists. Duplicate names and reused UIDs cause files to appear under the wrong owner later.

getent passwd | tail -5
getent group
cut -d: -f1,3 /etc/passwd | tail -10
cut -d: -f1,3 /etc/group

getent is the right tool because it queries through NSS, so it also shows accounts from LDAP or SSSD if the machine uses central authentication. Reading /etc/passwd directly hides those.

A /etc/passwd line has seven colon-separated fields:

alice:x:1001:1001:Alice Martin:/home/alice:/bin/bash

Field	Value	Meaning
1	alice	Login name
2	x	Placeholder. The hash lives in /etc/shadow.
3	1001	UID, the real identity. Never reused lightly.
4	1001	Primary GID
5	Alice Martin	Comment field, from -c
6	/home/alice	Home directory
7	/bin/bash	Login shell

/etc/group has four fields: group name, placeholder password, GID, and a comma-separated list of supplementary members. Notice that a user’s primary group is not listed there, which is why the primary group never shows up in groups output.

/etc/shadow is the file you never read directly. Its second field is the hashed password, and the rest record password ageing: last change, minimum and maximum age, warning period, and inactivity threshold. Because every account depends on it, it is mode 0640 and writable only by root and the shadow group.

See who is currently logged in and what ran recently:

who
w
last -n 10
lastlog | head -15
lslogins 2>/dev/null | head

Verification for this step: you can name every human account and every service account on the box, and you know the highest UID in use. That last number matters before Step 2.

Step 2: Create a New User Account

Use useradd for scripted work because it takes no prompts and its flags mean the same thing on every distribution. A first human account usually needs a home directory, a real shell and a comment field.

useradd -m -s /bin/bash -c "Alice Martin" alice
passwd alice

Add groups at creation time with -G, and pick a UID explicitly with -u when a UID has to line up with an external system or an NFS mount.

useradd -m -u 1500 -s /bin/bash -c "Alice Martin" -G developers alice
id alice
getent passwd alice
ls -ld /home/alice

On Debian and Ubuntu, adduser does the same job with prompts and sensible defaults:

adduser --disabled-password --gecos "" alice
adduser alice developers

Point	useradd	adduser
Origin	shadow-utils, present everywhere	login package, Debian and Ubuntu
Interface	Flags only, no prompts	Interactive prompts
Home directory	Depends on CREATE_HOME in /etc/login.defs	Creates one by default
Groups	-G at creation, -aG afterwards	adduser alice developers
Best for	Scripts, provisioning, containers	Interactive setup

Verification for this step: getent passwd alice prints the new line, id alice shows the UID, primary GID and group list, and the home directory exists on disk.

Step 3: Create and Assign Groups

A group is a named GID that files can belong to, which is how two people share a directory without sharing every permission. Create one with groupadd, optionally with an explicit GID.

groupadd developers
groupadd -g 2000 contractors
getent group developers

Every account has exactly one primary group and any number of supplementary groups. The primary group usually matches the username and is set at creation with -g. Supplementary groups are added afterwards, and this is where the classic mistake lives.

usermod -aG developers alice
id alice
groups alice

The -a means append. Without it, -G replaces the entire supplementary group list. Running usermod -G sudo alice on an account that was also in docker and adm strips those memberships, and if alice was your only sudo user you have just locked yourself out. This is the single most reported user management mistake on sysadmin forums, and it is entirely avoidable by always typing -aG.

gpasswd works from the group side instead:

gpasswd -a alice developers
gpasswd -d alice developers
gpasswd -M alice developers   # list members only, no change
gpasswd -A alice developers   # administrator rights on the group

For a shared project directory, set the group as owner and turn on the setgid bit so new files inherit it:

mkdir -p /srv/projects/atlas
chown root:developers /srv/projects/atlas
chmod 2775 /srv/projects/atlas
ls -ld /srv/projects/atlas

The leading 2 in 2775 is setgid. Without it, a file one user creates is owned by that user’s primary group, and the other members of the team lose write access immediately.

Verification for this step: id alice lists developers, ls -ld on the directory shows the 2 in the permission string, and a second user added to the group can create a file that the first user can still edit.

Step 4: Edit Users and Group Membership

usermod is the single tool for changing an existing account. Unlike useradd it has no -a safety net on most flags, so read the man page before running it on a real account: man usermod.

usermod -l amartin alice          # rename the login name
usermod -d /home/amartin -m alice # change home and move the contents
usermod -s /bin/zsh alice         # change login shell
usermod -g contractors alice      # change primary group
usermod -aG docker alice          # append a supplementary group
usermod -e 2026-12-31 alice       # set an account expiry date

The -m flag with -d is the part people miss. Without it, the home path changes in /etc/passwd but the files stay at the old location, and the user logs in to an empty directory.

Renaming touches mail spool and cron references too, so search before you commit to it:

grep -r "alice" /etc/cron* /etc/sudoers.d/ 2>/dev/null
getent passwd amartin
ls -ld /home/amartin

Verification for this step: getent passwd shows the new name, UID and shell, and getent group developers still lists the user.

Step 5: Control Login, Password, and sudo Access

Access is granted by group membership, not by editing a list of names. On Debian and Ubuntu the admin group is sudo, on RHEL-family systems it is wheel.

usermod -aG sudo alice
sudo -l -U alice

sudo -l -U confirms what the user can actually run. Run it right after the change instead of assuming.

Group membership is not the only route. A file in /etc/sudoers.d/ grants the same thing and survives a group change, which is useful when one person needs an unusual permission that nobody else should have.

EDITOR=nano visudo

Use visudo, never a text editor. It refuses to save a file with a syntax error, which matters because a broken sudoers file can leave the machine with no working sudo path at all.

Password changes and ageing:

passwd alice                 # interactive password change
chage -l alice                # show current policy
chage -M 90 -m 1 -W 14 alice  # max 90 days, min 1, warn 14 days before
chage -E 2026-12-31 alice     # account expires on a date
chage -I -1 -m 0 alice        # no minimum age, clear the expiry

Locking and unlocking keeps the account and its files intact while stopping every login method:

usermod -L alice
passwd -S alice
usermod -U alice

passwd -S alice
alice L 10/03/2026 0 99999 7 -1

The second field is the status. L means locked, P means a usable password hash. passwd -S is the quickest way to confirm an account state without reading /etc/shadow.

Verification for this step: sudo -l -U alice lists the privileges, chage -l alice shows the policy dates, and passwd -S shows the lock state.

Step 6: Set File and Directory Permissions

Account management only matters if the files agree with it. Permissions decide what each user can do; ownership decides which rules apply to whom.

ls -ld /srv/projects/atlas

drwxrwsr-x 2 root developers 4096 Sep 30 09:14 /srv/projects/atlas

Read it in three groups of three. The owner gets rwx, the group gets rws, and everyone else gets r-x. The s on the group position is the setgid bit from Step 3. A hyphen means that permission is not granted.

Letter	For files	For directories
r	Read contents	List entries
w	Write contents	Create and delete entries
x	Execute	Enter and traverse
s (setgid)	Runs with group ownership	New entries inherit the group
t (sticky)	Ignored	Only the owner can delete entries

Symbolic mode changes read more clearly than numbers:

chmod u+rwx,g+rx,o-rwx /srv/projects/atlas
chmod 750 /home/amartin/config.ini
chown amartin:developers /srv/projects/atlas
chgrp developers /srv/projects/atlas

chown takes user:group. chgrp changes only the group, which is what you want when the owner is correct. Avoid a blanket chown -R on a system directory. If you must recurse, scope it to the path you actually own and check it with ls afterwards.

Verification for this step: ls -ld shows the new owner, group and permission string, and a test account outside the group can no longer write.

Step 7: Remove or Safely Disable an Account

Locking and deleting are different decisions. Locking keeps the UID and the home directory so files stay attributed to the right owner. Deleting releases the UID for reuse, which is why it is the last option.

usermod -L alice
passwd -S alice

Also expire the account so nothing can extend it silently:

usermod -e 2026-12-31 alice
chage -l alice

When you are sure, delete the account. -r removes the home directory and the mail spool. Check it exists first, because the command is not reversible.

ls -ld /home/alice
userdel -r alice
getent passwd alice

Leave the UID out of /etc/passwd and the files become orphans owned by a number:

find / ( -nouser -o -nogroup ) 2>/dev/null | head -20

Then either chown them to a placeholder account or archive the directory before deleting it. If the account still has running processes, userdel refuses unless you force it, and forcing is a signal that you should stop the service properly first.

Groups go the same way, and groupdel also fails while the group is someone’s primary group:

groupdel contractors
getent group contractors

Verification for this step: getent returns nothing for both the user and the group, and find / -nouser shows either no leftover files or a list you have consciously handled.

Common Mistakes When You Manage Users and Groups in Linux

Running usermod -G without -a. This replaces the supplementary group list rather than adding to it. Fix: always use -aG, and run id username immediately afterwards to see the result. Before any sudo or group change, keep a second session open so a mistake does not end your only way back in.

Editing /etc/passwd or /etc/group in a text editor. A stray space or a missing field locks accounts across the whole machine, and nscd caching can make things worse. Fix: use the dedicated commands. If you must, work on a copy, use vipw for passwd, and verify with pwck -r and grpck.

Expecting group changes to apply immediately. A running session keeps the group list it was started with, so a user still gets permission denied right after usermod -aG. Fix: log out and back in, or start a new session with su – username. A brand new login shell inherits the new groups; the existing one does not.

Locking yourself out of sudo. Removing your own account from sudo or wheel, or running usermod -L on the account you are logged in as, ends root access through that route. Fix: recover from the GRUB menu into rescue mode, mount the filesystem, comment out the offending rule in /etc/sudoers, reboot. If you use cloud servers, the provider’s console or rescue image is the faster route.

Changing home with usermod -d and forgetting -m. The account points at a new path that does not exist and the files are still at the old one. Fix: check the target directory exists before you run it, and back up first.

Deleting a service account that is still running. Packages update their own system accounts, and a hand-edited UID breaks the files the service owns. Fix: stop the service first, back up the data directory, and leave packaged accounts under UID 1000 alone.

Forgetting to verify. Every command in this guide has a matching check. Ten seconds with getent, id and passwd -S is cheaper than an outage.

Frequently Asked Questions

Conclusion

Start every session with getent passwd, getent group and id on the account you are about to touch, so you know the current state and the highest UID in use. Make one change, then verify it with getent, id, groups, ls -ld or passwd -S before you make the next one. Once the account and group are correct, adjust ownership and permissions with chown, chgrp and chmod, and reach for usermod -L rather than userdel whenever you are not certain the account is finished.