Right, let’s talk about the three amigos of user management: useradd, usermod, and userdel. These are your low-level, no-frills tools for the job. They don’t hold your hand, they don’t ask you twenty questions, and they will happily let you shoot yourself in the foot if you’re not careful. Think of them as the grumpy but brilliant sysadmin who sits in the corner and gets stuff done—if you know the right incantations.

The first thing you need to understand is that these tools don’t work in a vacuum. They are intimately connected to four configuration files: /etc/default/useradd, /etc/login.defs, /etc/skel/, and of course, /etc/passwd and /etc/shadow. The defaults in these files are why your system behaves the way it does when you run a simple useradd bob. We’ll get into that.

The Defaults Aren’t Always Your Friends

Before you even think about adding a user, know what your system’s default settings are. This saves you from creating a user who can’t log in or has a hopelessly insecure shell.

cat /etc/default/useradd

You’ll see something like this:

GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/sh
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no

This tells you that by default, new users get a home directory under /home/, their shell is /bin/sh (which is probably just a symlink to bash, but don’t assume), and the contents of /etc/skel/ will be copied into their new home. The INACTIVE=-1 is a classic; it means “never disable the account after an expired password.” This is often not what you want for a secure system.

Actually Adding a Human User

The basic useradd command is… sparse. It does the absolute bare minimum. This is its most common failure mode. Let’s add our friend Bob.

sudo useradd bob
cat /etc/passwd | grep bob
# bob:x:1001:1001::/home/bob:/bin/sh

Look at that tragedy. Bob has no home directory (ls /home/bob will tell you it doesn’t exist), he has no password set (so he can’t log in), and he’s been given the default group bob with GID 1001. This is useless for a real person. You almost always want the -m (create home) and -s (set shell) flags. Let’s do it right.

sudo useradd -m -s /bin/bash bob

Now Bob has a home directory at /home/bob with the proper .bashrc and other skeleton files copied over. But he still can’t log in because he has no password. Let’s fix that. We don’t use useradd for this; we use the passwd command.

sudo passwd bob
# Enter new UNIX password: [you type a password for bob]
# Retype new UNIX password: [you type it again]

Yes, it’s a separate step. No, it’s not a flaw. It’s a feature. It forces you to consciously set a password (or consciously decide to lock the account). For scripting, you can echo a password to passwd --stdin (on some distros) or use chpasswd, but that’s a topic for another day.

Adding a System User (The Right Way)

Sometimes you’re not adding a person; you’re adding a user for an application, like a web server or a database. These users shouldn’t have login capabilities or home directories. This is where the -r and -s /usr/sbin/nologin flags come in.

sudo useradd -r -m -s /usr/sbin/nologin myapp

Wait, -r and -m? Yep. The -r flag means “create a system user” (typically with a UID under 1000). But it doesn’t create a home directory by default, which is daft because many applications need one. So we explicitly add -m. The -s /usr/sbin/nologin gives them a shell that politely refuses a login attempt, which is perfect for security.

Modifying the Beast

So you created Bob, but now you need to add him to the sudo group. Or maybe he’s changed his name to Robert and wants a new shell. Enter usermod.

sudo usermod -aG sudo bob    # Add Bob to the sudo group
sudo usermod -s /bin/zsh bob # Change his shell to Zsh
sudo usermod -l robert bob   # Change his login name from 'bob' to 'robert'

The -aG flags are critically important. The -G flag means “set the supplementary groups.” If you run usermod -G sudo bob, you will set Bob’s groups to only sudo, wiping him out of any other groups he was in. The -a flag means “append,” so you add the new group to his existing list. This is the number one pitfall with usermod. Forget the -a and you’ll get a very angry user.

Deleting (Or Not Really Deleting)

Finally, there’s userdel. The naive way is just sudo userdel bob. This removes Bob from /etc/passwd but leaves his home directory /home/bob sitting there, orphaned and taking up space. This is, to put it technically, dumb. You almost always want the -r flag to remove the home directory and mail spool along with the account.

sudo userdel -r bob

But here’s a pro tip: sometimes you don’t want to delete a user’s home directory right away. Maybe you need to archive their work. In that case, don’t use userdel yet. Instead, use usermod to lock the account and make it unusable, which preserves everything for a later audit or archive.

sudo usermod -L bob      # Lock the password
sudo usermod -s /usr/sbin/nologin bob  # Take away his shell
sudo chage -E 0 bob      # Expire the account

Now Bob’s account is a ghost. It exists in the filesystem but is completely inaccessible. You can safely tar up his home directory at your leisure and then come back with userdel -r when you’re ready to fully clean up. This is how you avoid those panic-induced “oh crap, I needed those files” moments.