Learn › RHCSA (EX200) › Users and Groups
useradd - a hands-on Linux lab on a real virtual machine.
Run the full local account lifecycle on RHEL 10. useradd NAME builds the user, a matching private group, and /home/NAME; flags -c comment, -s shell, -u uid, -G supplementary groups. usermod edits an existing account, and usermod -aG group user APPENDS a supplementary group (the -a is vital; bare -G replaces every supplementary group and silently locks people out). userdel -r removes the user and the home directory. Verify with getent passwd (the seven-field line) and id (UID, primary group, all supplementary groups). Human UIDs start at 1000 (login.defs UID_MIN). Serves EX200 users-and-groups: create, delete, and modify local user accounts.
A new engineer, Alice, starts Monday. The ticket says: give her an account on servera, put her name on it, and add her to the ops team's group so she can reach the shared tools. You know her login should be alice. But an account is not just a name. It is a numeric ID the kernel actually uses, a private group, a home directory with starter files, and a login shell. Skip any one of those and Alice logs in to a broken shell, or cannot log in at all.
This lesson is the account lifecycle: create a user, change a user, delete a user. Three commands do all of it. useradd builds the account, usermod edits it after the fact, and userdel tears it down. Around them sit two read-only commands, getent and id, that show you exactly what you built. This is the single most repeated task in the users-and-groups part of the exam.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2). A few values, like the exact UID and GID numbers, depend on what accounts the machine already has, so treat those numbers as illustrative. What is stable everywhere is the SHAPE: useradd makes a user plus a matching private group plus a home directory, getent passwd prints the seven-field account line, and id prints the UID, primary group, and every supplementary group.
A user account on Linux is a row in /etc/passwd, a numeric identity the kernel checks on every file access, plus a home directory and a login shell. Think of it like a badge for the building: it has an ID number, it opens certain doors (the groups you belong to), and it has a desk waiting for you (your home directory).
useradd is the tool that issues a new badge. usermod is the tool that reprints an existing badge with changes: a new group, a new shell, a new comment. userdel is the tool that revokes a badge and, if you ask, clears out the desk too. They are low-level and precise. They do exactly what you tell them and nothing more, which is why the exam uses them instead of a menu.
Every real system grows accounts over time. People join, people change teams, people leave. On a graphical desktop you might click through a Users panel, but on a server there is no panel, and on the exam there is no mouse. You get a terminal and a task that says create this user, put them in that group, give them this shell. useradd, usermod, and userdel are how that gets done, quickly and repeatably.
They also compose into scripts. Because each command is one line with predictable flags, you can create fifty accounts from a loop or a roster file. That is why learning the flags cold matters more than any GUI: the flags are the whole interface.
Start by building Alice's account. The simplest form is useradd NAME, but you almost always attach a comment naming the human behind the login, using -c. That comment field is called GECOS, and it is where the person's real name lives. A newly created account has no password yet, so it cannot log in until you set one; the clean way is to pipe a name:password pair into chpasswd.
Create the user alice with a comment, then give her a password:
useradd -c "Alice Admin" alice ; echo "alice:Pass1234" | chpasswd
prompt: [root@servera ~]# answer: useradd -c "Alice Admin" alice ; echo "alice:Pass1234" | chpasswd output: hint: The account builder is useradd, -c sets the comment, then the login name: useradd -c "Alice Admin" alice
No output, which is success: useradd and chpasswd are both silent when they work. In that one line, four things happened. The account alice was created, a private group also named alice was created to be her primary group, a home directory /home/alice was built and stocked with starter dotfiles, and a default login shell was assigned. The -c "Alice Admin" wrote her real name into the GECOS comment field. The chpasswd half set her password so she can actually log in. None of that prints anything, so you verify it with the next two commands.
Every local account is a single line in the /etc/passwd database, and getent passwd NAME prints that line. getent means get entries: it reads the system databases the same way a login does, so what it shows is what the system actually believes. The line has seven fields separated by colons.
Read back the account you just created:
getent passwd alice
prompt: [root@servera ~]# answer: getent passwd alice output: alice:x:1001:1001:Alice Admin:/home/alice:/bin/bash hint: The database reader is getent, then the database name passwd, then the login: getent passwd alice
Read that line field by field, split on the colons. alice is the login name. x means the real password hash lives safely in /etc/shadow, not here. The first 1001 is the UID, the numeric identity the kernel actually uses. The second 1001 is the GID of her primary group. Alice Admin is the GECOS comment you set with -c. /home/alice is her home directory. /bin/bash is her login shell. Seven fields, always in that order. This one line proves useradd did its job.
The UID here is 1001, not 1000. Human accounts start numbering at 1000, a floor set by UID_MIN in /etc/login.defs. This machine already ships a student account which took 1000, so alice got the next free number, 1001. On your machine the first human account might be 1000, or something else entirely, depending on what accounts already exist. The exact number is not the point; that it is at or above 1000, and that her primary GID matches her UID, is the point.
getent passwd shows the stored account line. id shows the live identity the kernel would grant: the UID, the primary group, and every supplementary group the user belongs to at once. It is the fastest way to answer which groups is this user in.
Print Alice's full identity:
id alice
prompt: [root@servera ~]# answer: id alice output: uid=1001(alice) gid=1001(alice) groups=1001(alice) hint: The identity command is id, then the login name: id alice
uid=1001(alice) is her numeric ID with the name in parentheses. gid=1001(alice) is her primary group, which useradd created as a private group matching her name. groups=1001(alice) lists every group she is a member of, and right now that is only her own private group, because you have not added her to any team group yet. That is the next move. Whenever a task says put user X in group Y and verify, id X is the verify.
This is the flag that trips up more exam takers than any other, so read it twice. To add a user to a supplementary group, you use usermod -aG GROUP USER. The -G names the supplementary group. The -a means APPEND. Together, -aG adds the group while keeping every group the user is already in.
The trap is dropping the -a. usermod -G ops alice does NOT add ops; it REPLACES her entire supplementary group list with only ops, silently removing her from every other group. On a real system that can cut off her access to everything. Always pair them as -aG. Add alice to the wheel group, the built-in administrators group:
usermod -aG wheel alice
prompt: [root@servera ~]# answer: usermod -aG wheel alice output: hint: The editor is usermod, -aG appends a supplementary group, then the login: usermod -aG wheel alice
Silent success again. Alice is now a member of wheel in addition to her private group. If you ran id alice now, groups= would list both 1001(alice) and wheel. The -a is what preserved her private group in that list. Read -aG as one unit, append-to-groups, and you will never accidentally wipe someone's memberships. usermod also does -c to change the comment, -s to change the shell, -u to change the UID, and -L / -U to lock and unlock the account.
usermod -G ops alice without the -a REPLACES every supplementary group at once. The command prints nothing and reports no error, so nothing warns you that you just removed alice from wheel, from ops's old peers, from everything except ops. This silent overwrite is the classic exam mistake and the classic real-world outage. If you mean to add a group, the flag is ALWAYS -aG. Reserve bare -G for the rare case where you truly want to set the complete list from scratch.
You set the comment with -c already. Three more flags round out useradd for the exam. -s SHELL sets the login shell, for example -s /sbin/nologin for a service account that must exist but must never log in interactively. -u UID forces a specific numeric ID instead of letting the system pick the next free one, useful when a UID must match across machines. -G g1,g2 adds supplementary groups at creation time, so you do not need a follow-up usermod.
You do not run a new terminal for these; they are extra flags on the same useradd you already know. A fuller creation might read useradd -c "Bob Ops" -s /bin/bash -u 1010 -G wheel bob, which sets the comment, shell, UID, and one supplementary group all at once. Reach for usermod only when the account already exists and you need to change it after the fact.
When someone leaves, you remove the account. Plain userdel NAME deletes the account row but leaves the home directory and its files behind as orphaned data owned by a now-missing UID. The -r flag removes the home directory and mail spool along with the account, which is what you almost always want for a clean departure.
Remove alice and her home directory in one move:
userdel -r alice
prompt: [root@servera ~]# answer: userdel -r alice output: hint: The remover is userdel, -r also deletes the home directory, then the login: userdel -r alice
Silent success. The account alice is gone from /etc/passwd, her private group is removed, and because of -r, /home/alice and its contents are deleted too. Run getent passwd alice now and it prints nothing and exits non-zero, which is how you confirm the account is truly gone. Without -r, that home directory would linger owned by an orphaned UID number, and if a later useradd reused 1001, the new user would inherit Alice's old files. The -r is what prevents that stale-data trap.
userdel -r will refuse or complain if the user is currently logged in or still owns running processes, and it does not hunt down files the user created outside their home directory. On the exam, deleting the account and its home with -r is the expected answer. In production you would also search the filesystem for stray files that user owned, but that is beyond what a delete task asks for.
Scaffolding off. No command is printed this time. You have every piece you need.
The account alice exists. A ticket says add her to the wheel group so she can run administrative commands, and it warns you in bold: do not remove her from any group she is already in. You know usermod is the editor. You know one flag names the supplementary group and one flag protects the memberships she already has. Which single command adds her to wheel while keeping everything else intact?
prompt: [root@servera ~]# answer: usermod -aG wheel alice output: hint: The editor is usermod. The append-to-groups flag is -aG, not bare -G. Then the login: usermod -aG wheel alice
usermod -aG wheel alice is the answer. The -a appends, so her existing memberships survive; the -G names wheel as the group to add. Drop the -a and you would have silently replaced her whole supplementary list with just wheel, the outage in a keystroke. Read -aG as a single word, append-to-groups, and this task is muscle memory. Verify it any time with id alice, where wheel will now appear in the groups= list.
You earned this cheat sheet. Every row is a form you just ran or built:
The one thing to burn in for the exam: when you ADD a user to a group, the flag is ALWAYS -aG. Bare -G on usermod replaces every supplementary group and silently locks people out.
Human UIDs start at 1000, the UID_MIN set in /etc/login.defs; anything below 1000 is a system account. If a task hands you a specific UID to use, set it with -u at creation. If you forget a flag, useradd -D prints the built-in defaults (default shell, home base, skeleton directory) that new accounts inherit, which is a fast way to check what a plain useradd would give you.
The practice terminal has walked you through the whole account lifecycle. useradd -c to create Alice with her real name, chpasswd to set her password, getent passwd and id to prove exactly what you built, usermod -aG to add her to a group without wiping the others, and userdel -r to remove the account and its home cleanly. Every one of those you typed yourself.
Operation Roster is where you run these against a real RHEL 10 machine. A full VM boots for you, with a work-order roster of accounts to create, comment, place into groups, and retire. The mission hands you objectives that use exactly what you practiced here. Create the users with the right comments and shells, append them to their team groups with -aG, verify each with id, and remove the departures with userdel -r. One difference from this lesson: the mission shows no commands. You read the objective, recall the useradd and usermod -aG and userdel -r forms, and type them. That recall is what makes it stick on exam day.
Finish the other users-and-groups lessons, then take on Operation Roster and build the real roster yourself.
Practice useradd, usermod, userdel in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.