Groups

What is it? #

A group is a named set of users. Files have a group owner, and group permissions apply to every member.

Groups exist to solve one problem cleanly: several people or processes need access to the same files, and giving them root would be far too much.

Every user has one primary group, used for files they create, and any number of secondary groups.

The typical server use is granting a deploy user and a web server user shared access to an application directory, without either being root.

Think of it like this #

A shared studio with a door code given to the whole team.

Each person still has their own locker, but the studio itself is accessible to anyone on the list. Adding a new team member is adding them to the list, not giving them the building's master key.

Simple example #

Your application runs as appuser and Nginx runs as www-data. Nginx needs to read static files that the application writes. A shared group solves this without making either root.

Code #

# What groups am I in?
groups
id ravi

# Create a group and add members
sudo groupadd webteam
sudo usermod -aG webteam ravi        # -a APPENDS; without it you replace all groups
sudo usermod -aG webteam www-data
# Group membership takes effect on the next login (or: newgrp webteam)

# Give a directory to a group
sudo chown -R appuser:webteam /srv/app/static
sudo chmod -R 750 /srv/app/static    # owner rwx, group r-x, others nothing

# The setgid bit: new files inherit the directory's group
sudo chmod g+s /srv/app/static
# Without this, files created by appuser get appuser's primary group,
# and www-data loses access to anything newly written.

ls -ld /srv/app/static
# drwxr-s--- 2 appuser webteam 4096 Sep 22 10:15 /srv/app/static
#        ↑ the s shows setgid is set

Useful system groups

sudo / wheel   members may use sudo
docker         members can control Docker — effectively root, treat with care
adm            read access to many log files
www-data       the user and group Nginx or Apache runs as (Debian/Ubuntu)

# Checking effective access
sudo -u www-data test -r /srv/app/static/main.css && echo "readable" || echo "denied"
namei -l /srv/app/static/main.css     # shows permissions at every path level

How it works #

usermod -aG appends a secondary group. The -a is essential; without it the command replaces the user's entire secondary group list, which commonly removes sudo access by accident.

Group changes apply to new sessions. A user already logged in keeps their old group list until they log out and back in, which explains the frequent "I added the group but it still says permission denied".

chown appuser:webteam sets the owner and the group separately. The owner gets the first permission triplet, group members the second, everyone else the third.

750 means the owner can read, write and execute, the group can read and execute, and others get nothing. For a directory, execute means the ability to enter it.

The setgid bit is the part people miss. Normally a new file takes the creating user's primary group, so files written by appuser would be owned by group appuser and become unreadable to www-data. With setgid on the directory, new files inherit the directory's group instead.

namei -l is invaluable for debugging access problems: it shows permissions at every level of the path. Access can fail because a parent directory is not traversable, not because of the file itself.

The docker group deserves its warning. Anyone in it can start a container mounting the host filesystem as root, so membership is equivalent to root access.

Real-world use #

The application-plus-web-server pattern above is extremely common: the app writes uploads or generated assets, the web server reads them, and a shared group with setgid keeps it working.

Log access is another case. Adding a user to adm lets them read system logs without sudo, which is a reasonable grant for someone who only needs to investigate.

Deployment users typically belong to a group that owns the release directory, so a deploy can write files that the running service can read.

Most "permission denied" incidents on servers trace back to one of three things: group changes not applied because the session was not restarted, a missing setgid bit on a shared directory, or a parent directory that is not traversable.

Reviewing group membership periodically is worth doing, particularly for sudo, docker and any group with broad file access.

Common mistakes #

• Using usermod -G without -a, wiping existing group memberships.
• Expecting group changes to apply to an existing session.
• Forgetting setgid, so newly created files are not accessible to the group.
• Adding users to the docker group without realising it is equivalent to root.
• Debugging only the file permissions when a parent directory blocks access.

Practice #

Create a group, add two users to it, and create a directory owned by that group with 2770 permissions. Have one user create a file in it and confirm the other can read it. Then remove the setgid bit, repeat, and observe the difference.