Learn › RHCSA (EX200) › Users and Groups
groupadd - a hands-on Linux lab on a real virtual machine.
Organize shared access with Linux groups. Create a group with groupadd NAME, understand the split between the one primary group (usermod -g, exactly one, shown as gid) and the many supplementary groups (usermod -aG, append, capital G), and read memberships back with getent group NAME and id NAME. Learn the punishing -G without -a trap that silently wipes a user out of every supplementary group. Serves EX200 users-groups: create, delete, and modify local groups and group memberships.
A new engineer named Alice joins the team. You created her account, she can log in, and everything looks fine. Then she tries to read a file that belongs to the devs group, and the system slams the door: permission denied. You check the file. It is group-readable. You check Alice. She is a real, working user. So why is she locked out? Because being a user is not enough. To share files with a team, Alice has to be a member of the team's group, and right now she is a member of exactly one group: her own.
Groups are how Linux lets a set of users share access without handing everyone the same password or making everything world-readable. This lesson is about creating groups and putting users into them: the one primary group every user must have, and the many supplementary groups they can join. It is a bread-and-butter exam task and a daily reality of running real systems.
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). The GID numbers you see, like 1002 and 1003, are assigned by the system in order and depend on what groups already exist, so your machine will hand out different numbers. What is stable everywhere is the SHAPE: groupadd makes a group, usermod -g sets the one primary group, usermod -aG adds supplementary groups, and getent and id read them back.
A group is a named list of users that Linux uses to grant shared permissions. Think of it as a keycard for a door. Instead of giving every engineer their own key to the devs project directory, you cut one keycard labeled devs and hand a copy to everyone who needs in. Change who is on the list, and access changes for all of them at once.
Every user has two kinds of group membership. The primary group is the single group a user is tagged with by default; there is exactly one, and it is the group that owns any new file that user creates. The supplementary groups (also called secondary groups) are extra memberships stacked on top; a user can belong to many, and each one grants access to whatever that group can reach. One primary, many supplementary. Keep that split in your head, because the two are set with different commands.
In real work, groups are how you organize access by team or by role. The developers share a code directory, the operators share a deploy area, the database admins share the database backups. You do not manage that by editing permissions on every file for every person. You create a group per team, put the right people in it, and set the files to be readable or writable by that group.
On the exam, the tasks are direct: create these groups, make this user a member of that group, set this user's primary group. The commands are groupadd to create, usermod to assign, and getent and id to verify. Master those four and the whole objective falls.
The simplest form is groupadd followed by the name you want. It creates a new group, assigns it the next available GID (group ID number), and writes a line into /etc/group. There is no output on success; it is silent, like most account tools, and you verify afterward.
Create two teams at once, then hand Alice membership in both. This is the exact rhythm a task asks for. Create the devs group:
groupadd devs
prompt: [root@servera ~]# answer: groupadd devs ; groupadd ops ; usermod -aG devs,ops alice output: hint: The group creator is groupadd NAME. Chain two with a semicolon, then usermod -aG devs,ops alice adds Alice to both.
Three commands, no output, all success. groupadd devs created the first group and groupadd ops the second, each getting the next free GID. Then usermod -aG devs,ops alice added Alice to both as supplementary groups in one shot: a comma-separated list, no spaces. The -a means append and the -G names supplementary groups. You will meet the trap for leaving out -a in a moment. For now, the groups exist and Alice is in them; the next steps prove it.
getent means get entries. Hand it the database name group and a group name, and it prints that group's line exactly as the system sees it, pulling from /etc/group and any network sources. Each line has four colon-separated fields: the group name, an x placeholder where a group password would go, the GID number, and the comma-separated list of members.
Read back the devs group to confirm Alice landed in it:
getent group devs
prompt: [root@servera ~]# answer: getent group devs output: devs:x:1002:alice hint: The entry reader is getent, the database is group, then the group name: getent group devs
The line reads devs:x:1002:alice. Field one is the group name devs. Field two is x, a placeholder that means group passwords are not stored here. Field three is the GID 1002, the number that actually identifies this group to the kernel. Field four is the member list, and there is Alice: the usermod -aG worked. Run getent group ops and you would see ops:x:1003:alice, the same shape with the next GID. The name is for humans; the GID is what the system uses.
The GID 1002 is assigned in sequence from whatever number was free when you ran groupadd. On your machine the same command may print 1005 or 1010. Do not memorize the number; read the field. What is guaranteed is the position: the GID is always the third colon-separated field, and the members are always the fourth.
getent group looks at one group and lists its members. id flips the view: hand it a username and it shows every group that user belongs to, primary and supplementary together, in one line. This is the single best command for answering does this user have the access I think they have.
Read Alice's full group picture:
id alice
prompt: [root@servera ~]# answer: id alice output: uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(devs),1003(ops) hint: The identity reader is id, then the username: id alice. It shows uid, primary gid, and all groups.
This one line holds the whole story. uid=1001(alice) is Alice's user ID. gid=1001(alice) is her primary group: notice it is her own private group, named after her, which useradd created automatically. The groups= list then shows every group she is in: her primary 1001(alice) plus the two supplementary groups you just added, 1002(devs) and 1003(ops). The gid= field is always the one primary group; the groups= field is all of them together. When a task says verify the user is in a group, id is the answer.
So far you added supplementary groups with usermod -aG. Setting the primary group is a different flag: lowercase -g (no a, no append, because a user has exactly one primary group and you are replacing it). The form is usermod -g <group> <user>. After it runs, the gid= field from id changes to the new group, and any file that user creates from then on is owned by it.
Make devs Alice's primary group instead of her private group:
usermod -g devs alice
prompt: [root@servera ~]# answer: usermod -g devs alice output: hint: Primary group is lowercase -g, exactly one group, no append: usermod -g devs alice
Silent success, like the other account tools. Alice's primary group is now devs. Run id alice and the gid= field would read gid=1002(devs) instead of her private group, while the groups= list still shows every membership. This is the sharp distinction to lock in: -g (lowercase, one group) sets the single primary; -aG (append, capital G) adds supplementary groups. Mix them up and you either fail to add a group or wipe out the memberships a user already had.
That change is a demonstration, not the end state you want here, so set Alice's primary group back to her own private group before you move on. usermod is silent on success either way:
usermod -g alice alice
prompt: [root@servera ~]# answer: usermod -g alice alice output: hint: Same flag, point it back at her own group: usermod -g alice alice.
Silent again, and Alice's primary group is back to her private alice group, exactly where useradd first put it. A -g command never touches supplementary groups, so her devs and ops memberships are untouched. Run id alice now and it reads what it did before: gid=1001(alice) for the primary, and the full groups= list still carrying 1002(devs) and 1003(ops). You proved you can move the primary group and put it back, and the membership picture is intact for the challenge.
The most punishing mistake in group work is dropping the -a from -aG. usermod -aG ops alice adds Alice to ops and keeps her other groups. usermod -G ops alice, without the -a, replaces her entire supplementary group list with only ops, silently kicking her out of devs and every other group. There is no warning and no undo. When you add a supplementary group, the flag is always -aG. Type the a.
Scaffolding off. No command is printed this time. You have every piece you need.
You just added Alice to the devs and ops groups. A task tells you to prove it: show, in a single line, Alice's user ID, her one primary group, and the full list of every group she belongs to. You do not want getent group, which shows one group's members; you want the view centered on the user, listing all her groups at once. Which single command, given her username, prints that uid, gid, and groups= summary?
prompt: [root@servera ~]# answer: id alice output: uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(devs),1003(ops) hint: Not getent group. It is the identity reader centered on the user: id, then the username alice.
id alice prints exactly one line: uid=1001(alice), the primary gid=1001(alice), and the full groups= list including 1002(devs) and 1003(ops). That is the verify step for every group-membership task on the exam. getent group devs would have listed who is in one group, but only id centers the view on the user and shows the primary and all supplementary groups together. When a task says confirm this user is in these groups, id earns the check.
You earned this cheat sheet. Every row is a form you just ran or built:
The one thing to burn in for the exam: primary group is lowercase -g and there is exactly one; supplementary groups are -aG and there can be many. Never write -G without the -a, or you erase every supplementary group the user already had.
When a task lists several supplementary groups for one user, add them all in a single command with a comma list and no spaces: usermod -aG devs,ops,dba alice. It is faster than three separate usermod calls and, more importantly, there is no window where you might forget the -a on a later call and wipe the earlier additions.
The practice terminal walked you through the whole loop. groupadd to create a team, usermod -aG to add a user to supplementary groups, usermod -g to set the one primary group, and getent group and id to read it all back. Every one of those you typed yourself.
The users-groups mission, Operation Roster, is where you run these against a real RHEL 10 machine. A full VM boots for you, with real accounts and a real /etc/group file waiting. The mission hands you a roster of users and teams: create the groups, set each person's primary group, add the right people to the right supplementary groups, and prove the memberships with id. One difference from this lesson: the mission shows no commands. You read the objective, recall the groupadd and usermod -aG and usermod -g forms, and type them. That recall is what makes it stick on exam day.
Finish the other users-groups lessons, then go build a real roster in Operation Roster.
Practice Groups: Primary and Supplementary in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.