The “/etc/group” file contains a colon “:” delimited list of groups and group members. Each line has four fields.

• Name: The unique name of the group.
• Password: Not used. This will always hold “x.”
• Group ID: The unique group identifier.
• Users: A comma-delimited list of the members of the group. The list is usually empty for system and daemon accounts.

To dump the contents of the file to the terminal window, you can use cat, but it’s more convenient to be able to scroll through the contents of the file with less.

less /etc/group

Most of the entries at the top of the list have no members, although the “adm” group has two, and the “cdrom” group has one.

If we want to discover the groups a specific user is in, we can use grep to search for entries with their user account name. This isn’t our task at hand. We want to see everyone who is a member of a group, not the groups that one person belongs to. But it is instructive for us to take a look.

grep "dave" /etc/group

The entries that contain the string “dave” are listed for us. And tucked away amongst them is a sign that things might not be as simple as we thought.

When a user is added to Linux, the default action is to place them in a group with the same name as their user account. This is their primary group. Any other groups they are added to are known as secondary groups.

The problem is that users are not listed as members of their primary groups. That’s why the group “dave” is not showing any members, although the user “dave” is a member of that group.

Of course, system administrators can change the primary group of any user to that of any other group. That means a user can be a member of any group but they won’t be listed as such in the “/etc/group” file. That’s one issue.

The second issue is that the “/etc/group” file isn’t a single source of truth. Modern Linux installations may well store user and group information in more places than “/etc/passwd” and “/etc/group”, especially in corporate situations where services like Lightweight Directory Access Protocol are deployed. By only looking in one place, you might not be seeing the big picture.

In our test scenario, we created four groups for a development department. They are:

• resteam: The research team.
• devteam: The development team.
• pvqteam: The product verification and quality team.
• docteam: The documentation team.

We added people to these teams. Some people are in more than one team. If we open the “/etc/group” file in less and scroll to the bottom of the file, we’ll see the new groups and group members. At least, as many members as the “/etc/group” file knows about.

If we want to extract a single group, we can search using grep. The caret “^” represents the start of a line.

grep "^devteam" /etc/group

This extracts the “devteam” entry from the file and lists all the group members. Or does it?

The getent Command

The getent command checks multiple databases for user group information, not just “/etc/group.” We’ll use getent to show us the user groups.

getent group

Using getent with the group option produces—on this test machine—the same results as using the “/etc/group” file. That’s because we’re not using LDAP or any other centralized naming service. So there are no other sources for getent to refer to.

It’s no surprise then, that the results tally with those from the “/etc/group” file. Perhaps what we’re seeing really is the reality of the situation. Maybe everything is straightforward and—on this computer—what you see is what you get? Let’s reserve judgment on that.

The getent command can look at a single group for us. We’ll look at the “devteam” group.

getent group devteam

We get exactly the same results as before. There is a way to dig deeper though.

The lid Command

The lid command is part of the libuser collection of tools. It was already installed on our Fedora 36 test computer but had to be installed on the Ubuntu 22.04 and Manjaro 21 ones.

Also, the command is called lid on Fedora and Manjaro, but on Ubuntu, you need to use libuser-lid.

To install the command on Ubuntu, type:

sudo apt install libuser

On Manjaro, libuser is installed from the AUR, so you’ll need to use your favorite AUR helper. We used yay.

yay libuser

You can use libuser-lid to display group information about groups or users. To show the groups an individual is in, pass their user account name on the command line. On Fedora and Manjaro remember to use lid instead of libuser-lid.

sudo libuser-lib dave

To see the members of a group, use the -g (group) option along with the name of the group.

sudo libuser-lid -g devteam

Lo and behold, a user called “francis” has appeared as a member of the list. This is the first time we’ve seen him. He isn’t listed in “/etc/group” and getent didn’t discover him either.

Let’s look at a few users with the groups command.

groups abigail

groups hayden

groups francis

• User “abigail” is in a group called “abigail” and two other groups, “resteam” and “devteam.”
• User “hayden” is in a group called “hayden” and two other groups, “pvqteam” and “docteam.”
• User “francis” is in a single group, the “devteam” group. It’s notable that they are not in a group named “francis.”

We know that every user must be a member of a primary group and that by default the primary group has a GID and name that match the user’s UID and account name. It would appear there’s something different about the user “francis.”

Let’s use the id command and see what the UID and GIDs tell us.

id abigail

id francis

User “abigail” has a UID of 1002, and a GID of 1002. They are in three groups, one of which is called “abigail.” It has a GID of 1002. This is their default primary group.

User “francis” has a GID of 1019, which matches the GID of the “devteam” group. This user has either been assigned a new primary group, or the “devteam” group was set as their primary group when this user was added to the system.

Whichever one it was, only libuser-lid detected them and reported their presence in the “devteam” group.