SGID Directories for Collaboration

chmod - a hands-on Linux lab on a real virtual machine.

Build a shared team directory with the SGID bit so every file created inside inherits the directory group instead of the creator personal group. Covers the special permission bits (setuid 4, setgid 2, sticky 1), the exam recipe chgrp <group <dir then chmod 2770 <dir, reading the s in the group slot with ls -ld, proving group inheritance on a real file, and adding the sticky bit (mode 3770) when users should delete only their own files. On RHEL 10 ACLs are dropped from RHCSA, so SGID group directories are THE collaboration tool. Serves EX200: create and configure set-GID directories for collaboration.

The dev team shares one folder, /srv/team. Amir creates report.txt there. Now Bela, on the same team, opens it to add a line and the editor refuses: permission denied. She is in the group. The folder is group-writable. Yet she is locked out of a file her own teammate just made.

Look at the file and the reason is right there in the group column: the file belongs to Amir's PERSONAL group, not the team's. Everything a user creates lands under their own primary group by default, so a shared folder quietly fills with files nobody else in the group can edit. This lesson fixes that with one bit on the directory, and on RHEL 10 it is the main collaboration tool you have.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2). The dates, sizes, and the small inode count (6) in ls -ld are whatever that machine had at capture time, so yours will differ. What is stable everywhere is the SHAPE: the s in the group slot, and the group column reading devs on files made inside.

Every file has three special permission bits that sit above the normal read/write/execute nine. In octal they are a leading digit: setuid is 4, setgid is 2, and the sticky bit is 1. You add them the same way you add any permission, with chmod.

The one that solves collaboration is setgid (2) on a directory, often called SGID. When a directory has SGID set, every file or subdirectory created inside it inherits the DIRECTORY's group, not the creator's primary group. Set the folder's group to devs once, flip the SGID bit, and from then on everything born inside belongs to devs automatically. The whole team can read and write each other's files.

You might reach for an access control list here, a per-user permission overlay. On RHEL 10 you cannot: ACLs (setfacl and getfacl) were dropped from the RHCSA objectives. Collaboration is now done the classic way, with group ownership, a sane umask, and the SGID bit on a shared directory.

This is a deliberate simplification, not a loss. An SGID group directory is the pattern real teams have used for decades, and it is exactly what the exam now expects for a shared folder. Two commands set the group with chgrp and set the bit with chmod, and the directory does the rest for every file created afterward.

First see the problem plainly. A file created in an ordinary directory takes the creator's primary group. Here root creates report.txt inside /srv/team while the directory is still plain, and you read the group column with ls -l.

Before you run it, decide what you expect in the group field. The command is:

ls -l /srv/team/report.txt

prompt: [root@servera ~]# answer: ls -l /srv/team/report.txt output: -rw-r--r--. 1 root devs 0 Jul 5 20:35 /srv/team/report.txt hint: List the one file long-form so you can see its owner and group columns: ls -l /srv/team/report.txt

The third and fourth columns are owner and group: root and devs. In this capture the directory ALREADY had SGID, so the file inherited devs. On a plain directory that fourth column would instead read the creator's own primary group (for root, the root group), and that is the bug from the cold open: teammates cannot edit each other's files because each file carries a different personal group. The next steps set the bit that forces the devs group you see here.

SGID makes files inherit the directory's group, so first the directory must belong to the RIGHT group. chgrp changes a file or directory's group owner. Point it at the team group devs and the folder /srv/team.

The command is:

chgrp devs /srv/team

prompt: [root@servera ~]# answer: chgrp devs /srv/team output: hint: chgrp takes the group name then the path: chgrp devs /srv/team

No output, which is success. The directory's group is now devs. This step matters because SGID inherits whatever group the directory carries. If you set SGID while the directory still belongs to root, every new file would inherit root, not the team, and collaboration would silently fail. Group first, then the bit.

Now the bit. chmod 2770 sets four things at once: the leading 2 is SGID, then 7 (rwx) for the owner, 7 (rwx) for the group, and 0 (no access) for others. That is the exam shape for a private team folder: the group can read, write, and enter; outsiders are shut out; and SGID forces the group on everything created inside.

You could also flip just the bit symbolically with chmod g+s /srv/team, but the numeric form sets access and the bit together, so it is the faster move. Run:

chmod 2770 /srv/team

prompt: [root@servera ~]# answer: chmod 2770 /srv/team output: hint: The leading 2 is SGID, then 770 for owner, group, others: chmod 2770 /srv/team

No output again. The directory now has SGID plus rwx for owner and group and nothing for others. Setting the bit and the permissions in one command is why numeric mode is worth memorizing: 2770 is the canonical shared-team-folder line. The next step reads the directory back so you can SEE the bit you just set.

chmod 770 and chmod 2770 look almost identical but are not. The leading 2 is the entire point: drop it and you get a group-writable folder with NO inheritance, so files keep landing in personal groups and the collaboration bug returns. When the task says shared or collaborative directory, the mode is four digits starting with 2.

ls -ld on a directory shows the directory's own line instead of its contents (the -d means the directory itself). Read the permission string and look at the group's execute slot. On a normal directory that slot is x. With SGID set it becomes a lowercase s.

Read the directory:

ls -ld /srv/team

prompt: [root@servera ~]# answer: ls -ld /srv/team output: drwxrws---. 2 root devs 6 Jul 5 20:35 /srv/team hint: List the directory itself, not its contents, with the -d flag: ls -ld /srv/team

Read the permission string drwxrws---. The leading d is directory. Then owner rwx, then the group triad rws: that lowercase s where an x would sit IS the SGID bit. Others get ---, no access, exactly what 770 gave them. The group column reads devs, so the folder belongs to the team and inheritance is armed. A lowercase s means SGID AND group-execute are both on; a capital S would warn you that SGID is set but group-execute is missing, usually a mistake.

This is the payoff the whole lesson was building toward. With the directory carrying devs and SGID set, any file created inside should be born into the devs group no matter who made it. That is the difference between a folder that merely looks shared and one that truly is.

Read a file that was created inside the SGID directory and check its group column:

ls -l /srv/team/report.txt

prompt: [root@servera ~]# answer: ls -l /srv/team/report.txt output: -rw-r--r--. 1 root devs 0 Jul 5 20:35 /srv/team/report.txt hint: List the file long-form and read the fourth column, the group: ls -l /srv/team/report.txt

The group column reads devs, the directory's group, not the creator's personal group. That is SGID doing its one job. Every file the team creates in /srv/team from now on carries devs, so any member with group write can edit it. The cold open is solved: Bela can open Amir's report.txt because it belongs to the team, not to Amir alone.

One more bit rounds this out. In a folder everyone can write, anyone can also DELETE anyone else's file, because delete permission comes from write on the directory, not on the file. The sticky bit (1) fixes that: with it set, a user can delete only files they own. It is the same bit /tmp uses so users cannot wipe each other's temp files.

Stack it on top of SGID by making the leading digit 3 (that is 2 for SGID plus 1 for sticky), giving mode 3770. You would run chmod 3770 /srv/team, and ls -ld would then show a t in the others-execute slot alongside the group s. Use 2770 for a plain shared folder; reach for 3770 when the team is large enough that accidental deletes are a real risk.

Scaffolding off. No command is printed this time. You have built the whole thing.

You have set the group and flipped the SGID bit on /srv/team. Before you tell the team it is ready, you want to SEE the directory's own permission line and confirm the lowercase s sits in the group slot, without listing any of the files inside. Which single command shows the directory itself long-form?

prompt: [root@servera ~]# answer: ls -ld /srv/team output: drwxrws---. 2 root devs 6 Jul 5 20:35 /srv/team hint: It is ls with a long flag and the flag that shows the directory itself, not its contents. That flag is -d.

ls -ld /srv/team prints the directory's own line, and drwxrws--- confirms it: the s in the group triad is SGID, devs is the group, and --- locks out everyone else. That single line is your proof the shared folder is correct before anyone relies on it. Pair it with a test file's ls -l and you have both halves: the bit is set AND real files inherit the group.

You earned this cheat sheet. Every row is a form you just ran or built:

The special-bit values to burn in: setuid 4, setgid 2, sticky 1. For a shared team directory the recipe is two moves: chgrp <group> <dir> to give the folder to the team, then chmod 2770 <dir> to set SGID and permissions in one shot. Group first, bit second, always.

A lowercase s in the group slot means SGID AND group-execute are both on, which is what you want. A capital S means SGID is set but group-execute is missing, so files inherit the group but the group cannot enter the directory. If you ever see rwS, add group-execute with chmod g+x (or just re-run chmod 2770).

The practice terminal has walked you through the full collaboration pattern: ls -l to catch a file landing in the wrong group, chgrp devs to hand the directory to the team, chmod 2770 to set SGID and permissions in one command, ls -ld to confirm the s in the group slot, and the inheritance proof that a new file is born into devs. You also learned when to reach for 3770 and the sticky bit. Every one of those you typed yourself.

The file-systems module mission is where you build this on a real RHEL 10 machine. A full VM boots for you, with a real group and a real shared directory waiting. The mission hands you an objective that uses exactly what you practiced: create a collaborative directory, set its group, set SGID so files inherit that group, and prove it with a test file. One difference from this lesson: the mission shows no commands. You read the objective, recall chgrp then chmod 2770, and type it. That recall is what makes it stick on exam day.

Finish the other file-systems lessons, then go build a shared folder that actually shares.

Practice SGID Directories for Collaboration in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.