Managing User Groups and Privileges with the sudo and groups Commands

Managing user groups and privileges with the sudo and groups commands means knowing exactly which groups an account belongs to, adding or removing membership, and granting elevated rights through a group rule instead of editing every user. This guide walks through inspection, group creation, sudoers drop-in files and the checks that confirm a change actually took effect.

Work on one user first, verify, then repeat for the rest. Group changes only apply to new logins, so a quick re-login or newgrp is part of every test.

Before you start

• A Linux VPS running Ubuntu 22.04 or 24.04, Debian 12, or AlmaLinux/Rocky 8 or 9, with root access or an account that already has full sudo rights.
• SSH access to the server. Find the IP and the login user in your VPS provider's control panel; the examples use 203.0.113.10 and the user deploy.
• A second SSH session open as root while you edit sudoers. If a rule is wrong you can fix it from that session instead of the browser console.
• The sudo, adduser/useradd and groupadd tools, which are installed by default on all supported images.

Log in as root or as your existing sudo user, then confirm who you are:

whoami
id

Inspect current group membership

Start by reading the state of the system. groups shows the groups of the current user, id shows numeric IDs and every group including the primary one, and getent reads the same data from NSS, so it also covers groups from LDAP or SSSD if you use them.

groups
groups deploy
id deploy
getent group sudo wheel developers

getent group <name> prints one line per group:

developers:x:1002:deploy,ana

The four fields are group name, password placeholder, GID and the comma-separated member list. Note that users whose primary group is developers do not appear in that list — check the GID in the id output before assuming the group is unused.

To see what sudo already allows for an account, query it as root:

sudo -l -U deploy

That output lists the sudo rules matching deploy, which is the fastest way to verify a change without switching users.

Create groups and add users

Create a group for each team or role, then add members to it.

sudo groupadd developers
sudo usermod -aG developers deploy

The -a flag means append. Without it, usermod -G replaces the entire list of supplementary groups, and the user silently loses memberships such as sudo.

On Debian and Ubuntu, gpasswd and adduser are convenient alternatives:

sudo gpasswd -a deploy developers
sudo adduser deploy developers

Verify immediately:

id deploy

You should see developers in the groups= list. If it is missing, the command failed — read the error rather than repeating it.

Primary versus supplementary groups

The primary group is the one assigned to new files the user creates. Change it only when the workflow depends on it:

sudo usermod -g developers deploy

This replaces the previous primary group. Existing files keep their old ownership; new files in the user's home directory will belong to developers instead of deploy.

Remove a user from a group

sudo gpasswd -d deploy developers
sudo deluser deploy developers

The first command works on every distribution, the second is Debian and Ubuntu only. Confirm with id deploy.

Grant sudo access through a group

Group-based sudo is easier to audit than per-user rules: you change membership, not policy.

The privileged group differs by family. Debian and Ubuntu use sudo; AlmaLinux, Rocky and RHEL use wheel. Check which one exists and already has a rule:

getent group sudo
getent group wheel

Then add the user to the matching group:

sudo usermod -aG sudo deploy

sudo usermap -aG wheel deploy

Add your own group rule

Create a drop-in file instead of editing /etc/sudoers. Always open it with visudo so the syntax is validated before saving:

sudo visudo -f /etc/sudoers.d/developers

Add the rule, using % for a group name:

%developers ALL=(ALL:ALL) ALL

Save and exit. visudo refuses to write a file with a syntax error, which protects you from a broken sudo setup.

To limit a group to specific commands, list them explicitly:

%webops ALL=(root) /bin/systemctl restart nginx, /bin/systemctl reload nginx

Members then run sudo systemctl restart nginx but nothing else. For password-free rules and command whitelists in more detail, see give a user sudo access to specific commands only and sudo without a password.

Share a directory between group members

A common reason to create a group is a shared upload or deployment folder. Set the group and the setgid bit so new files inherit the group:

sudo mkdir -p /srv/app/shared
sudo chown root:developers /srv/app/shared
sudo chmod 2770 /srv/app/shared

2770 means setgid plus rwx for owner and group, nothing for others. Any file created inside inherits developers as its group, so every member can edit it. If you need finer control than the classic bits, see Linux file system permissions: ACL versus standard permissions.

Audit membership across the server

Group drift is normal on servers that live for years. List members with:

getent group developers
awk -F: '$1=="developers"{print $4}' /etc/group

To find every group a user belongs to, including the primary one:

id -nG deploy

And to list all groups with their GIDs:

getent group | sort -t: -k3 -n | tail -n 20

Run these before and after changes so you can prove what changed.

Check it works

Open a new session as the user — group membership is applied at login, not to sessions that are already open.

su - deploy
id
groups

Then test the privilege itself:

sudo -k
sudo whoami

sudo -k clears the cached timestamp so you are prompted for the password again. The expected output is root. If you added a restricted command rule, test a permitted command and one that should fail:

sudo systemctl reload nginx
sudo cat /etc/shadow

The second command should be denied. That denial is the proof the restriction works.

Troubleshooting

• id still shows the old groups after usermod → existing sessions keep their group list. Log out and back in, or run newgrp developers in the current shell, then check with id again.
• User lost sudo after a usermod command → usermod -G was used without -a, replacing the supplementary list. Re-add the group with sudo usermod -aG sudo deploy, then re-login.
• deploy is not in the sudoers file. This incident will be reported. → The account is not in the privileged group and no drop-in rule matches it. Confirm the group name for your distribution (sudo versus wheel) and check the rule with sudo -l -U deploy.
• sudo: no valid sudoers sources found, quitting or syntax error → A bad /etc/sudoers.d file. Log in as root in your open session, fix it with visudo -f, or remove the file with rm /etc/sudoers.d/developers. If root SSH is unavailable, use the browser console in your VPS provider's control panel.
• Permissions look right but writes still fail → The parent directory lacks the setgid bit or the group execute bit. Re-check with ls -ld /srv/app/shared and compare against id.
• Membership changes not visible to a service → Long-running processes, including web servers and PHP-FPM, cache group membership at start. Restart them with sudo systemctl restart <service>.

Next steps

• Add a user to a group in Linux for the plain-language version of membership changes.
• Create a sudo user on Ubuntu, Debian, AlmaLinux and Rocky Linux if you are still setting up the first admin account.
• List users and groups on a Linux server to audit accounts before you change privileges.
• Lock, unlock or disable a Linux user account when someone leaves the team and membership must be revoked cleanly.