Linux Group Management : Creating, Modifying, and Managing Groups

Objective

Groups are how Linux organizes users and controls access to files, directories, and system resources. This guide covers the commands and files you need to manage them confidently. By the end, you will know how to:

• Create groups with groupadd, including custom GIDs and system groups
• Assign users to supplementary and primary groups with usermod and gpasswd
• Modify group names and GIDs with groupmod
• View membership information with groups, id, and getent
• Delegate membership management using group administrators with gpasswd
• Delete groups safely with groupdel
• Build a shared project directory that uses group permissions correctly
• Apply these skills to LFCS exam tasks and real multi-user systems

Permissions on a multi-user system quickly become unmanageable if you grant access user by user. Groups solve this: you grant access to a group once, then control who has it by changing membership. Adding a new developer to a project becomes a single command instead of a round of permission edits across dozens of directories.

How Linux Groups Work

Every user belongs to exactly one primary group and any number of supplementary groups. The two roles behave differently, and mixing them up is behind many group-related mistakes.

Aspect	Primary Group	Supplementary Groups
How many per user	Exactly one	Zero or more
Where it is stored	The GID field in /etc/passwd	The member list in /etc/group
Group of newly created files	Yes, files get this group by default	No, unless the directory has the setgid bit
Purpose	Default ownership identity	Additional access to shared resources
Typical command	usermod -g	usermod -aG

Most modern distributions also create a user private group for each new user: a group with the same name as the user and the user as its only member. This is why a new user alice usually has a primary group called alice.

Where Group Information Is Stored

File	Contents	Readable by
/etc/group	Group name, GID, and the list of member users	All users
/etc/gshadow	Group password hash, group administrators, and members	Root only
/etc/passwd	Each user's primary GID	All users
/etc/login.defs	GID ranges and whether user private groups are created	All users (read), root (write)

# Look at a group entry in /etc/group
grep "^developers:" /etc/group

# Format: group_name:password:GID:member_list
# developers:x:2001:alice,bob
#     |      |   |       |
#   name     |  GID   members (supplementary)
#      'x' means any password is stored in /etc/gshadow

# View the matching /etc/gshadow entry (requires root)
sudo grep "^developers:" /etc/gshadow

# Format: group_name:password_hash:administrators:members
# developers:!:alice:alice,bob

# Regular groups typically start at GID 1000. System groups use lower numbers.
grep -E "^(GID_MIN|GID_MAX|SYS_GID_MIN|SYS_GID_MAX)" /etc/login.defs

Creating Groups with groupadd

# Create a group (the system picks the next available GID)
groupadd developers

# Create a group with a specific GID
groupadd -g 2000 devops

# Create a system group (GID from the system range, used for services)
groupadd -r appservice

# Verify the groups were created
getent group developers devops appservice

Option	What It Does	Example
-g GID	Assign a specific GID	groupadd -g 2000 devops
-r	Create a system group with a GID in the system range	groupadd -r appservice
-f	Exit successfully if the group already exists (useful in scripts)	groupadd -f developers
-o	Allow a non-unique GID (use with -g, rarely a good idea)	groupadd -o -g 2000 devops2

Viewing Group Information

# Show all groups a user belongs to
groups alice

# Sample output:
# alice : alice developers wheel

# Show UID, primary GID, and all group memberships
id alice

# Sample output:
# uid=1001(alice) gid=1001(alice) groups=1001(alice),2001(developers),10(wheel)

# Show only the group names
id -nG alice

# Show only the primary group name
id -gn alice

# Look up a group (also works when groups come from LDAP or other sources)
getent group developers

# List all groups on the system
getent group

# Show which groups the current shell session is using
groups
id

getent is worth remembering. Reading /etc/group with grep only shows local groups, while getent queries every configured source, so it also finds groups that come from a directory service.

Adding Users to Groups

There are two common ways to manage membership: usermod and gpasswd. Both work, and knowing both helps because exam tasks and real systems use either.

# Add a user to a supplementary group (keeps existing groups)
usermod -aG developers alice

# Add a user to several groups at once
usermod -aG developers,devops alice

# Change a user's primary group
usermod -g developers alice

# Add a user to a group using gpasswd
gpasswd -a bob developers

# Remove a user from a group
gpasswd -d bob developers

# Set the complete member list (replaces all existing members)
gpasswd -M alice,bob,charlie developers

# Create a user with a primary group and supplementary groups from the start
useradd -m -g developers -G devops,wheel dave

# Verify
id alice
getent group developers

Group changes do not apply to sessions that are already open. A user who was just added to a group must log out and back in before the new membership takes effect. To use a new group immediately without logging out, start a shell with it:

# Start a new shell with developers as the active primary group
newgrp developers

# Run a single command with a group's privileges
sg developers -c "touch /srv/projects/notes.txt"

Modifying Groups with groupmod

# Rename a group
groupmod -n engineering developers

# Change a group's GID
groupmod -g 2500 engineering

# Verify
getent group engineering

Renaming and changing a GID behave very differently:

• Renaming is safe. Files store the numeric GID, not the name. After groupmod -n, every file simply shows the new group name.
• Changing the GID is not automatic for files. Files on disk keep the old numeric GID, so after groupmod -g they appear owned by a number with no matching group.
  • Find and fix them: find / -xdev -gid 2001 -exec chgrp -h engineering {} +
  • Run the search before or right after the change, and choose the file systems to search deliberately

Group Administrators with gpasswd

A group administrator can add and remove members of one specific group without needing root. This lets you delegate day-to-day membership changes to a team lead while keeping the rest of the system locked down.

# Make alice an administrator of the developers group
gpasswd -A alice developers

# Make several users administrators (this replaces the existing administrator list)
gpasswd -A alice,bob developers

# Verify administrators in /etc/gshadow (third field)
sudo grep "^developers:" /etc/gshadow

# As alice, add a member without root privileges
gpasswd -a charlie developers

# As alice, remove a member
gpasswd -d charlie developers

A group administrator can manage membership for that group only. They cannot create or delete groups, change GIDs, or touch any other group.

Deleting Groups with groupdel

# Delete a group
groupdel developers

# groupdel refuses to remove a group that is a user's primary group
# groupdel: cannot remove the primary group of user 'alice'

# Fix: change the user's primary group first, then delete
usermod -g users alice
groupdel developers

# Check for leftover files owned by the deleted group's GID
find / -xdev -gid 2001 2>/dev/null

# Deleting a user with -r removes the home directory
# and normally removes the user's private group as well
userdel -r bob

Deleting a group does not delete or reassign the files it owned. Those files remain with a bare numeric GID. Always check for leftover files and give them a new group, or you may leave data that nobody can manage and, worse, a GID that a future group could reuse and unexpectedly inherit access to.

Practical Example: A Shared Project Directory

This is the most common real-world use of groups: several people working in one directory where everyone can read and write each other's files.

# 1. Create the group and the users who will share the directory
groupadd projectteam
useradd -m -G projectteam alice
useradd -m -G projectteam bob

# 2. Create the shared directory
mkdir -p /srv/project

# 3. Give the group ownership
chgrp projectteam /srv/project

# 4. Set permissions: owner and group full access, others none
#    The leading 2 is the setgid bit
chmod 2770 /srv/project

# 5. Verify (look for the 's' in the group execute position)
ls -ld /srv/project
# drwxrws---. 2 root projectteam 6 Oct 15 10:00 /srv/project

# 6. Test as alice, then check what bob sees
sudo -u alice touch /srv/project/alice-notes.txt
ls -l /srv/project

Why 2770 works:

• 770 gives the owner and the group full access and everyone else nothing
• The setgid bit (the leading 2) makes every new file and subdirectory inherit the directory's group, projectteam, instead of the creator's primary group
  • Without it, a file alice creates would belong to her private group alice, and bob could not edit it
• New files still follow the creator's umask. With the common default umask of 022, a new file is group read-only. If the team needs group write on new files, set the umask to 002 for those users.

Groups That Grant Administrative Access

Membership in certain groups grants real power, so treat changes to them carefully. The name of the administrative group differs between distribution families, which matters for LFCS because the exam is distribution-agnostic.

Group	Typical Distributions	What Membership Grants
wheel	RHEL, Rocky Linux, AlmaLinux, Fedora	Full sudo access in the default configuration
sudo	Ubuntu, Debian	Full sudo access in the default configuration
docker	Systems with Docker installed	Control of the Docker daemon, which is effectively root-equivalent access to the host
adm	Debian family	Permission to read many system log files
systemd-journal	Most systemd distributions	Permission to read the full system journal

# Grant sudo access on a Red Hat family system
usermod -aG wheel alice

# Grant sudo access on a Debian or Ubuntu system
usermod -aG sudo alice

# Check who currently has administrative access
getent group wheel
getent group sudo

Common Mistakes

• Using usermod -G without -a. usermod -G docker alice replaces all of alice's supplementary groups with only docker. usermod -aG docker alice appends.
  • This is the single most common group mistake and it can silently remove someone's sudo access
• Expecting group changes to apply immediately. A user's existing sessions keep their old group list. The user must log out and back in, or use newgrp.
  • When a user says "I was added to the group but I still get permission denied", this is almost always why
• Trying to delete a user's primary group. groupdel refuses, with a clear error. Reassign the user's primary group first.
• Changing a GID and forgetting the files. groupmod -g updates the group but not file ownership on disk, leaving files owned by an unnamed numeric GID.
  • Use find with chgrp to bring the files across
• Forgetting the setgid bit on shared directories. Without it, files take the creator's primary group and the rest of the team cannot access them.
• Using gpasswd -A or -M and expecting an append. Both replace the whole list. Use gpasswd -a and -d for single additions and removals.
• Editing /etc/group by hand with a normal editor. A typo can break group lookups. If you must edit directly, use vigr, which locks the file and checks the syntax on save.

Quick Reference

Task	Command
Create a group	groupadd groupname
Create a group with a specific GID	groupadd -g 2000 groupname
Create a system group	groupadd -r groupname
Add a user to a supplementary group	usermod -aG groupname username
Change a user's primary group	usermod -g groupname username
Add or remove a single member	gpasswd -a user group or gpasswd -d user group
Set group administrators	gpasswd -A user group
Rename a group	groupmod -n newname oldname
Change a group's GID	groupmod -g NEWGID groupname
Show a user's groups	groups username or id username
Look up a group	getent group groupname
Delete a group	groupdel groupname
Set up a shared directory	chgrp group dir then chmod 2770 dir
Use a new group without logging out	newgrp groupname

Group Management and the LFCS Exam

Managing local users and groups is part of the LFCS exam. Tasks in this area typically ask you to:

• Create a group, sometimes with a specified GID
• Add existing users to supplementary groups without removing their other memberships
• Change a user's primary group
• Rename a group or change its GID
• Set up a directory so a group can share files, using group ownership and the setgid bit
• Verify the result with id, groups, and getent group

As with user accounts, the safest habit is to verify every change after you make it. Read the result back with id or getent instead of assuming the command did what you intended.

Practice This in a Real Environment

Group commands are short, but the behaviours around them are not obvious from reading: why a user still gets permission denied after being added to a group, what happens to files when a GID changes, or why a shared directory only works with the setgid bit. Those things click when you run the commands and then inspect the results. LinuxCert.Guru has a dedicated hands-on lab for this topic: Group Management. It covers creating groups, managing memberships and primary groups, modifying group names and GIDs, delegating with gpasswd, and cleaning up safely, with auto-graded tasks that check your configuration.

Practice the Group Management lab at LinuxCert.Guru → https://linuxcert.guru/lfcs/?name=lfcs-group-management

Conclusion

Groups are the mechanism that makes Linux access control manageable at scale. Once you understand the difference between primary and supplementary groups, the commands follow naturally:

• groupadd creates groups, with -g for a specific GID and -r for system groups
• usermod -aG adds users to supplementary groups. Always include -a.
• gpasswd manages single additions, removals, and group administrators
• groupmod renames groups safely, but changing a GID leaves existing files behind
• groupdel removes groups, but cannot remove a user's primary group, and does not touch the files the group owned
• Shared directories need group ownership plus the setgid bit, for example chmod 2770
• Group changes apply at the next login, or immediately with newgrp
• Verify with id, groups, and getent group after every change

Together with user account management, this is the foundation for managing secure multi-user Linux systems. The next step is understanding how new users get their default environment, so that everyone you create starts with the right settings.