Table of Contents
Understanding user creation and removal
In an intermediate Linux administration context, creating and removing users is about more than just adding a login name. It involves choosing how the account behaves, where its files live, which groups it belongs to, and what happens when the account is no longer needed. This chapter focuses on the practical command line tools and the most common options you will use when managing users on a typical Linux system.
Always verify which distribution you are using and consult man pages like man useradd and man adduser for exact behavior, because defaults and helper tools can differ between systems.
Tools used for user management
Most Linux systems provide a low level tool called useradd and a companion tool userdel for removing users. On some distributions, you will also find a high level interactive tool called adduser which wraps useradd and asks questions in a friendlier way.
When you run these tools, they modify system user databases such as /etc/passwd, /etc/shadow, and group files. Another pair of tools, passwd and chage, are used to set and adjust passwords and password expiry, but the details of those belong in password policy topics.
For the purposes of this chapter, you can think of useradd as the canonical way to create accounts in scripts and automated setups, while adduser is helpful when you create accounts manually.
Creating a basic user account
On a typical system with useradd, the simplest account creation looks like this:
sudo useradd alice
This command creates an entry for alice in the system user database. However, what exactly happens depends on defaults controlled by login.defs and configuration in /etc/default/useradd or similar. On many distributions, the default behavior is to:
Create a private group for the user with the same name as the user.
Assign a default home directory, often /home/alice.
Set a default shell such as /bin/bash.
Populate the home directory with files copied from a skeleton directory, often /etc/skel.
If you run useradd without additional options, you might end up with a user that has no home directory or no password, depending on the distribution defaults. For that reason, administrators often specify their intentions explicitly.
A more explicit and safer pattern is:
sudo useradd -m -s /bin/bash alice
sudo passwd alice
Here -m instructs useradd to create the home directory if it does not exist, and -s sets the login shell. passwd then prompts you to set a password for alice so that the account can be used for interactive logins.
On systems where useradd does not create a home directory by default, forgetting the -m option results in an account that can log in but has no personal directory, which often breaks common workflows and can confuse new users.
Controlling home directories
Home directories are the main place where ordinary users store their own files and configuration. When you create a user, you can choose the location of the home directory with the -d option to useradd.
For example:
sudo useradd -m -d /srv/projects/alice -s /bin/bash alice
This command creates alice with a home directory at /srv/projects/alice. The -m flag instructs the tool to create that directory and populate it with files from the skeleton directory.
The skeleton directory is used to provide default configuration files at account creation. It is usually located at /etc/skel. You can override it with the -k option:
sudo useradd -m -k /etc/skel-developers -s /bin/bash devuser
This copies files from /etc/skel-developers into the new home directory. This pattern is useful if you maintain different template environments for different classes of users, such as developers and regular office users.
Primary and supplementary groups during creation
The group or groups a user belongs to control access to shared files and resources. When you create a user, a default primary group is assigned. On many modern systems, this is a per user group with the same name as the user, such as alice:alice.
You can specify a primary group explicitly with the -g option. The group must already exist:
sudo groupadd staff
sudo useradd -m -g staff -s /bin/bash bob
Now bob has staff as the primary group. This is often used in environments where files created by members of the staff group are meant to be shared.
To add the new user to additional groups at creation time, use the -G option with a comma separated list:
sudo useradd -m -s /bin/bash -G wheel,developers carol
Here carol has a standard primary group (typically carol) and is also a member of the wheel and developers supplementary groups. On some distributions, the wheel group or a similar group name is associated with administrative privileges through sudo.
If you want the primary group to be one of the groups from your list, you must specify it with -g. The -G option only sets supplementary groups, never the primary group.
System accounts versus regular accounts
Not all users on a system correspond to human users. Many services and daemons run under dedicated system accounts. These accounts usually:
Do not have login shells, or use a shell like /usr/sbin/nologin.
Often have no home directory, or a directory that is not used interactively.
Have user IDs in a reserved range for system use.
To create such a system account, you can use the -r option with useradd:
sudo useradd -r -s /usr/sbin/nologin -d /var/lib/myservice myserviceThis command asks the system to allocate a UID in the system range and defines a non interactive shell. The home directory points at a service related directory, which might hold configuration or data but is not meant as a login environment.
Creating clear system accounts for services helps keep privileges separated, which limits the impact of potential vulnerabilities.
Locking and disabling accounts
Sometimes you do not want to remove a user entirely, but you need to prevent logins. This is common when someone leaves a company but their files must remain available. The usual approach is to lock the account.
You can lock an account using the -L option with usermod:
sudo usermod -L aliceThis modifies the password entry in a way that disables password based logins. To unlock the account later, use:
sudo usermod -U alice
Another pattern is to set the login shell to something non interactive such as /usr/sbin/nologin while leaving the password alone:
sudo usermod -s /usr/sbin/nologin aliceThis prevents interactive logins through typical shells, but keeps files and group memberships intact. Other authentication methods or specialized services may still be able to use the account, so you should always check how your environment authenticates users.
Interactive creation with adduser
Some distributions, especially Debian based ones, provide adduser as a friendlier wrapper. Instead of specifying many flags, you run:
sudo adduser aliceThe tool will then ask you a series of questions such as full name, room number, work phone, and more. It will typically:
Create the home directory and copy in skeleton files.
Set the login shell from a default.
Assign a private group.
Prompt you for an initial password.
Since adduser primarily calls useradd under the hood, it respects the same low level configuration files. As an administrator, you should still understand useradd because it is more portable and is often the only option on non Debian derived systems.
Removing user accounts with userdel
When a user no longer needs access to the system, you remove their account with userdel. The most basic command is:
sudo userdel alice
This deletes the user entry from /etc/passwd and related databases, but on many systems it does not delete the home directory by default. The files remain on disk, but their ownership may now show the numeric user ID instead of a name, because the name is no longer recognized.
If you want to remove the account and also delete the home directory and the user's mail spool, you can use:
sudo userdel -r alice
The -r option instructs userdel to remove the home directory contents. This is a destructive action and cannot be reversed easily, so it should be used only when you are sure that no one needs the user's files.
Never run userdel -r on an account if you have not confirmed that all important data has been backed up or migrated. Deleting a home directory removes all configuration, scripts, and personal files inside it.
Handling processes and logged in users during removal
If the user is currently logged in or has running processes, removal becomes more complicated. On some systems, userdel will refuse to remove such an account without a special option. Even if it allows the operation, you can end up with processes that run under an orphan UID that no longer resolves to a user name.
Before removing an account, it is good practice to check for running processes:
ps -u alice
If you see active processes, you can ask the user to log out or terminate those processes in a controlled way. Only once there are no processes running should you proceed with userdel. This avoids inconsistent states and unexpected issues with services or sessions that still rely on the account.
In more complex environments, you might also need to check for cron jobs, systemd units, or other scheduled tasks associated with the user, and disable or remove them separately.
Strategies for preserving or migrating user data
Account removal often has implications beyond simple access control. In many organizations, user home directories contain project files, documentation, and scripts that other team members still need.
One conservative strategy is to:
Lock the account with usermod -L.
Change the shell to a non interactive one.
Leave the home directory intact.
This immediately prevents new logins while giving you time to review or reassign files. After evaluation, you can archive the home directory, for example with tar, and then proceed to remove the account and delete the original directory if desired.
You can also change ownership of important directories to a shared account or another user with chown before removal, but that action belongs to ownership administration topics and is only mentioned here to show how it connects to user removal.
Naming conventions and UID ranges
While the exact ranges are configured in system files, most Linux distributions separate user ID ranges into areas for system users and for human users. When you create system accounts using useradd -r, the tool typically chooses a UID from the system range. For regular user accounts, it chooses from a higher range.
You can override this behavior with the -u option:
sudo useradd -m -u 1050 -s /bin/bash alice
This assigns UID 1050 explicitly. You should only do this if you understand the UID allocation strategy on your system and you are avoiding collisions with existing IDs. It is often used when migrating users from another system where UIDs must remain consistent.
Consistent UIDs are particularly important when multiple machines share home directories over a network filesystem because file ownership is stored numerically, not by user name.
Summary of safe practices
When you create users, specify your intentions explicitly instead of relying completely on distribution defaults. Use -m to create home directories, choose appropriate shells, assign primary and supplementary groups, and decide whether the account is a regular or a system account.
When removing users, decide whether you want to preserve data, and handle running processes and scheduled jobs gracefully. Locking accounts before deletion gives you time to verify that important files have been backed up or reassigned. With these practices, user creation and removal become predictable operations that support both security and continuity on your Linux systems.