Learn › Linux Foundations › Important Files and Paths
cat - a hands-on Linux lab on a real virtual machine.
Read the Linux group roster in /etc/group. The four colon-separated fields (name, password placeholder, GID, members), how the member list works, why a primary group can look empty, and why one name in the sudo group grants admin rights. Structure-only: your groups and numbers vary, so the drills teach the format.
In the last lesson you read /etc/passwd, the list of every account on the machine. But an account on its own cannot do much. What lets one account into the locked rooms, the ability to run admin commands, reach the printer, drive the containers, is not written in passwd at all. It lives in a second file, one line per team, that decides who belongs to what.
That file is /etc/group. When Linux asks a very common question, "is this user allowed to do that?", the answer often comes down to one thing: which groups is the user in? This lesson teaches you to read the roster that holds the answer.
The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. /etc/group is a real system file, and its contents are different on every machine. The lines shown here are one representative example. On the live machine at the end of the module, you run cat /etc/group against your own system and read your own groups.
A group is a named team of user accounts. Instead of granting a permission to each account one at a time, Linux grants it to a group, then drops accounts into that group. Everyone in the group inherits the access. A group is a guest list; the permission is the door it opens.
/etc/group is the plain-text file that records every group on the system and who belongs to it. One line per group. It is the companion to /etc/passwd: passwd answers "who are the accounts," and group answers "which teams are they on." You read it the same way you read any text file, with cat.
Before you break down a single field, just look at the whole roster. cat prints a file to the screen; point it at the path and the file spills out:
cat /etc/group
prompt: student@linuxcamp:~$ answer: cat /etc/group output: root:x:0: sudo:x:27:student docker:x:998:student,alice student:x:1000: hint: Type cat, a space, then the full path: cat /etc/group
Those four lines are trimmed from one example machine. A real /etc/group has dozens of lines, and the group names, the ID numbers, and the members will all be different on your system. What is identical everywhere is the SHAPE of each line, and that shape is the whole lesson.
Every line in /etc/group is one group, and every line has the same four parts, separated by colons (:). Read them left to right. Take the line sudo:x:27:student and split it on the colons:
The colon is the divider, so the fields line up as name : password : GID : members. Field two is nearly always a bare x; you can read past it. The two fields that carry the meaning are the GID in field three and the member list in field four.
GID stands for group ID. Just as every account has a number (its UID, from the passwd lesson), every group has a number, its GID. The system tracks groups by that number, not by the name. The name is there for humans.
Field four is where you look to answer "who is on this team?" It is a comma-separated list of usernames, with no spaces. One name, or several, or none at all. Look again at the docker line from the roster:
docker:x:998:student,alice
prompt: student@linuxcamp:~$ answer: cat /etc/group output: root:x:0: sudo:x:27:student docker:x:998:student,alice student:x:1000: hint: Same command as before prints the whole file; read the docker line: cat /etc/group
Split docker:x:998:student,alice on its colons and field four is student,alice: two usernames, separated by a comma. That is the whole membership of the docker group, two people who may drive the container engine. The sudo line above it has just one name in field four, student. And the root line ends in a bare colon with nothing after it: field four is empty, so root has no listed extra members. An empty field four is normal and common, and the next step explains exactly why.
Here is the part that trips up almost everyone. Look at the student line:
student:x:1000:
Field four is empty. Nobody is listed. Yet the account student absolutely belongs to the student group. How can a group have a member whose name is not in its own member list?
Because field four only lists supplementary members, the extra teams a user was added to on top of their own. Every account has ONE primary group, and that link is recorded back in /etc/passwd (field four of the passwd line was a GID), not repeated here. So a user's primary group usually shows an empty member list in /etc/group, even though they belong to it. The membership is real; it is just written on the other side.
Do not read an empty field four as "this group has no members." It means "this group has no EXTRA members listed here." Anyone whose PRIMARY group this is belongs to it through /etc/passwd, and will not appear in the /etc/group line at all. To see every group a user is really in, primary and supplementary together, you use the groups or id command, which is a lesson of its own.
Now the payoff. This tiny format is how a user gets, or loses, the right to run admin commands. On most systems, being in the sudo group is what lets you run commands as the superuser. And membership in that group is decided by exactly one thing: whether your name is in field four of the sudo line.
Read the sudo line one more time and say out loud what it grants before you look at the explanation:
sudo:x:27:student
prompt: student@linuxcamp:~$ answer: cat /etc/group output: root:x:0: sudo:x:27:student docker:x:998:student,alice student:x:1000: hint: Print the file and read field four of the sudo line: cat /etc/group
Field one is sudo, the admin group. Field three is its GID, 27. Field four is student. That single name in field four is the whole reason the account student can run sudo commands: it was added to the sudo group, so it inherits that group's power. Add a name to that field and you hand out admin rights; remove it and you take them back. On your machine the admin group might be called wheel instead of sudo, and its members will be whoever your system trusts. The mechanism is identical: the member list of the admin group IS the list of who can act as root.
Scaffolding off. No breakdown this time. You have every piece you need.
You land on an unfamiliar machine and you print /etc/group. One line reads:
audio:x:29:student,bob
Before you read on, decide in your head: what is the group's name, what is its GID, and who are its listed members? Then print the file to fix the format in muscle memory:
prompt: student@linuxcamp:~$ answer: cat /etc/group output: root:x:0: sudo:x:27:student audio:x:29:student,bob docker:x:998:student,alice student:x:1000: hint: The command is the same one you have used all lesson: cat /etc/group
Split audio:x:29:student,bob on its colons. Field one is the name, audio. Field two is the placeholder x, which you skip. Field three is the GID, 29. Field four is the member list, student,bob, two supplementary members who may use the sound hardware. You read a raw line with no help and pulled all four fields out of it, which is exactly what the real machine will ask of you. Your own file will hold different groups and numbers, but every line splits the same four ways.
You earned this cheat sheet. It is the whole file in one table:
And the three facts that keep you out of trouble. Read a line by splitting on the colons. Field four lists only the SUPPLEMENTARY members, so a primary group can look empty. And the member list of the admin group (sudo or wheel) is the list of who can act as root.
/etc/group and /etc/passwd are a pair. passwd names the accounts and points each one at its PRIMARY group by GID. group names the teams and lists the SUPPLEMENTARY members. Read together, they tell you every user's full identity: who they are, and every team they are on.
The practice terminal has shown you the shape of /etc/group. You can print it with cat, split any line into its four fields, read the member list, and explain why an empty list does not mean an empty group. Every one of those you typed yourself.
The Important Files module ends with one real Linux machine, the Important Files capstone mission, and that is where you read /etc/group for real. A VM boots just for you, with its own accounts and its own groups. It hands you objectives that use exactly what you practiced across this module: reading the account list, the group roster, the hostname, and the rest of the files that define a system. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.
Finish the other Important Files lessons, then go read a real system's groups for yourself.
Practice /etc/group in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.