How Setgid Directories Pass the Bit to New Subdirectories

When you create a directory inside a directory with the set-group-ID (SGID) bit set, Linux carries that bit onto the new subdirectory. Clear SGID on the parent and later subdirectories stop inheriting it; directories created earlier keep their existing mode. This walkthrough verifies that behavior with Bash commands and recorded output from the disposable lab.

Lab environment

• Disposable Linux container, working under /work.
• Bash, GNU stat, mkdir, chmod, find, and test.
• The lab sets umask 022 explicitly and runs as UID/GID 1000.
• The source bundle includes the exact tested commands and captured verification output.

The lab demonstrates SGID-bit propagation. It does not compare ownership across different groups: the runner had only one effective primary GID.

Prerequisites

• A Linux shell with Bash and GNU stat.
• Write access to a disposable working directory.
• For exact reproduction, download the commands.sh and README.md files from the article’s tested source bundle on GitHub.

What SGID changes on a directory

The SGID bit has two useful directory effects. A new subdirectory inherits SGID from its parent, and new entries normally inherit the parent directory’s group. This lab checks the first effect. Since the runner has one effective group, it deliberately makes no claim about comparing group ownership across multiple groups.

The Linux mkdir(2) documentation describes SGID inheritance for a newly created subdirectory. The inode(7) page describes the directory semantics, and chmod(1) documents g-s as the symbolic mode for clearing the bit. Red Hat’s shared-directory guidance explains why administrators use SGID on team directories: it helps keep new content associated with the directory’s group.

Create a disposable sandbox

Run these commands from a throwaway working directory. The first removal command targets only the named sandbox in your current directory, so do not run this in a location where that name contains files you need.

umask 022
rm -rf setgid-sandbox
mkdir -p setgid-sandbox/setgid-lab
cd setgid-sandbox/setgid-lab

Create an SGID parent and a plain comparison directory, then inspect their modes:

mkdir shared plain
chmod 2775 shared
chmod 0775 plain
stat -c '%a %A %n' shared plain

The shared directory should show mode 2775, or drwxrwsr-x. The plain directory should show 775, or drwxrwxr-x. The leading 2 in 2775 is the SGID bit.

Compare newly created subdirectories

Create one child under each parent and inspect the special bit and mode:

mkdir shared/nested_before_clear
mkdir plain/nested_before_clear
stat -c '%a %A %n' shared/nested_before_clear plain/nested_before_clear
test -g shared && echo 'shared has SGID'
test -g shared/nested_before_clear && echo 'shared child has SGID'
test -g plain/nested_before_clear || echo 'plain child has no SGID'

The recorded run produced mode 2755 for the child under shared and 755 for the child under plain. With umask 022, ordinary write bits are removed; the parent’s SGID bit determines whether the new child receives the special bit. Default ACLs or filesystem-specific inheritance settings can change the ordinary mode calculation.

Captured output from the actual lab commands on 23 October 2026.

The compact results below show both sides of the test, including the child created after SGID was cleared:

Rendered from the actual recorded lab output on 23 October 2026.

Clear SGID and test a later child

Remove SGID from the parent, confirm that the existing child still has it, and then create another child:

chmod g-s shared
stat -c '%a %A %n' shared
test -g shared || echo 'shared has no SGID now'
test -g shared/nested_before_clear && echo 'older child still has SGID'
mkdir shared/nested_after_clear
stat -c '%a %A %n' shared/nested_before_clear shared/nested_after_clear
test -g shared/nested_after_clear || echo 'new child has no SGID'

The verified results were:

• The parent changed from 2775 to 775.
• The existing child remained 2755 and kept SGID.
• The new child was 755 and had no SGID.

Clearing SGID affects future directory creation; it does not retroactively change existing subdirectories. If you need to standardize existing content, inspect and change those directories separately.

Why this matters

SGID is useful on shared project directories because it helps new content follow the directory’s group policy. When a new subdirectory has an unexpected mode, inspect the parent’s mode at the time it was created. The related umask 022 article explains how the mask affects ordinary directory permissions.

Limits and cleanup

This test used a disposable sandbox and one effective GID. It did not test multiuser races, network filesystems, or ownership inheritance across different groups. Default ACLs and filesystem settings can also change the results.

The shell ends in setgid-sandbox/setgid-lab. Return to the original working directory before removing the sandbox and the evidence file:

cd ../..
rm -rf setgid-sandbox details.txt

Takeaway

A new subdirectory inherits SGID when its parent has SGID at creation time. Clearing the bit on the parent stops future inheritance, while existing children retain the mode they already have. For more Linux permissions practice, see the RHCSA Certification Training course.

Example source files

The tested Bash commands, README, and recorded output on GitHub are the exact source bundle used for this lab.

Sources

• mkdir(2) - Linux manual page
• inode(7) - Linux manual page
• chmod(1) - Linux manual page
• Managing file system permissions - Red Hat Enterprise Linux 9
• Configuring and using network file services - Red Hat Enterprise Linux 9