Hands-on Lab·Linux Foundation Certified System Administrator

Permissions, ownership and the bits above them

Nine bits, three more above them, and an ACL layer on top. The parts that get examined are the ones that are not obvious: what execute means on a directory, why chmod -R 755 is almost always wrong, what setgid does to a shared directory, and the fact that removing an ACL entry does not remove the ACL.

Essential Commands Guide 9 of 38 Intermediate

PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
LVM2.03.31 (Ubuntu) / 2.03.36 (AlmaLinux)
nftables1.1.6 (Ubuntu) / 1.1.5 (AlmaLinux)
TimeAbout 22 min

getfacl and setfacl come from the acl package, which is installed on RHEL 10 by default and is NOT installed on Ubuntu 26.04 - the capture installs it. The umask on both lab hosts is 002.

Firewallufw 0.36.2 enabled but reporting inactive / firewalld active
Network confignetplan + systemd-networkd / NetworkManager 1.56.0

Both distributions, because the commands on this page differ between them. Every output is captured on the host it belongs to.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LFCS-A01	192.168.0.70	Ubuntu 26.04 LTS	Primary host - most guides run only here	2 Core	4 GB	50 GB
LFCS-C01	192.168.0.72	AlmaLinux 10.2	The other distribution - dnf, firewalld and NetworkManager	2 Core	4 GB	50 GB

This guide includes

Use this for the permissions marks. This matters because chmod -R 644 on a tree locks you out of your own directories - execute means something different there, and capital X exists for exactly that case.

finding the umask that decided a new file's mode, and using chmod in both spellings
learning what execute means on a directory, and how chmod -R with a file mode locks you out
using capital X, which exists for that case
setting the three bits above the nine, and changing owner and group
adding ACLs for when nine bits are not enough, including the entry that stays after you remove it

Before you start

guide 5 - stat and the mode string.

The mode a new file gets, and the umask that decided it
No chmod anywhere - just a new file and a new directory.
bash Example session
```
$mkdir -p ~/ess/perm && cd ~/ess/perm && umask; echo "--- and symbolically:"; umask -S002--- and symbolically:u=rwx,g=rwx,o=rx$cd ~/ess/perm && touch newfile && mkdir newdir && stat -c '%A %a %n' newfile newdir-rw-rw-r-- 664 newfiledrwxrwxr-x 775 newdir$cd ~/ess/perm && bash -c 'um=$(umask); echo "umask       $um"; printf "file  0666 & ~umask = 0%o\n" $((0666 & ~0$um)); printf "dir   0777 & ~umask = 0%o\n" $((0777 & ~0$um))'umask       0002file  0666 & ~umask = 0664dir   0777 & ~umask = 0775
```
Note
Files start from 0666 and directories from 0777, and the umask is subtracted from both. Directories get execute because you cannot enter one without it. Files do not, because a data file has no business being executable.

002, not 022. Debian and Ubuntu use 002 for a user with a private group of their own, so new files are group-writable. On a system with 022 the same commands give 644 and 755. Never assume - run umask.

umask -S prints it as symbols, which is easier to read and is what you want when explaining it to somebody.

Setting it applies to the shell and its children only - the capture sets 077 and gets a 600 file, then puts it back. For a persistent change it goes in a profile or a systemd unit's UMask=.

Expected resultumask 002 / u=rwx,g=rwx,o=rx; the file 664 and the directory 775; and the arithmetic 0666 & ~umask = 0664, 0777 & ~umask = 0775.

Success conditionYou can predict the mode of a file you have not created yet.
chmod, both spellings
Octal and symbolic, on the same file.
bash Example session
```
$cd ~/ess/perm && chmod 640 newfile && stat -c '%A %a' newfile && chmod u=rw,g=r,o= newfile && stat -c '%A %a' newfile-rw-r----- 640-rw-r----- 640$cd ~/ess/perm && chmod g+w newfile && stat -c '%A %a' newfile; chmod a-w newfile && stat -c '%A %a' newfile; chmod +x newfile && stat -c '%A %a' newfile-rw-rw---- 660-r--r----- 440-r-xr-x--x 551
```
Note
Octal sets the whole mode; symbolic changes part of it. chmod 640 says "be exactly this". chmod g+w says "add this to whatever is there", which is why you can end up somewhere you did not intend.

Look at the 440 -> 551 step. chmod +x added execute for user, group *and* other - so a file that was r--r----- became r-xr-x--x, giving other an execute bit it did not have a read bit for. +x with no prefix means a+x, and u+x is what people usually mean.

= is the one that removes things: chmod g=r sets group to exactly read, clearing write and execute.

Expected result640 from the octal form and from u=rw,g=r,o=; then +w on group giving 660, a-w giving 440, and +x giving 551.

Success conditionYou can set a mode either way.
What execute means on a directory
Three modes on the same directory, and what each one lets you do.
bash Example session
```
$cd ~/ess/perm && mkdir -p nox/inner && touch nox/inner/file && chmod 500 nox && ls nox && echo "--- r-x: listing works"; chmod 400 nox && ls nox 2>&1 | tail -1; echo "--- r--: listing works, but:"; ls nox/inner 2>&1 | tail -1inner--- r-x: listing worksinner--- r--: listing works, but:ls: cannot open file 'nox/inner': Permission denied$cd ~/ess/perm && chmod 100 nox && ls nox 2>&1 | tail -1; echo "--- --x: cannot list, but CAN traverse:"; cat nox/inner/file 2>&1 | tail -1; echo "(empty file, no error = traversal worked)"; chmod 700 noxls: cannot open directory 'nox': Permission denied--- --x: cannot list, but CAN traverse:(empty file, no error = traversal worked)
```
Note
On a directory, r means "read the list of names" and x means "use the names". They are genuinely independent, which is the single most examined detail in this domain.

r-- gives you the names and nothing else - you can see inner and cannot stat it, so ls -l fails on every entry while ls works.

--x is the opposite and is useful. You cannot list the directory, but if you already know a filename you can reach it. That is how a directory of user home directories works: mode 711 lets everyone traverse to their own without reading the list of who else exists.

Which is why chmod -R 644 on a tree is a disaster - the next step.

Expected resultr-x listing fine; r-- listing the names but cannot open file 'nox/inner'; --x refusing to list at all but still letting cat nox/inner/file through.

Success conditionYou can explain the difference between r and x on a directory.
So chmod -R with a file mode locks you out
chmod -R 644 on a directory tree. It exits 0.
bash Example session
```
$cd ~/ess/x && chmod -R 644 . ; echo "exit $?"; ls 2>&1 | tail -1; find . 2>&1 | tail -2exit 0ls: cannot open file '.': Permission deniedfind: ‘.’: Permission deniedfind: Failed to restore initial working directory: /home/sysadmin/ess/x: Permission denied$cd ~/ess && chmod 755 x x/sub && cd x && find . | sort; echo "--- put the directories' x back and it works again"../f./sub./sub/g--- put the directories' x back and it works again$cd ~/ess/x && chmod 644 f sub/g && stat -c '%A %n' . sub f sub/g; echo "--- files 644, directories 755: the state you actually wanted"drwxr-xr-x .drwxr-xr-x sub-rw-r--r-- f-rw-r--r-- sub/g--- files 644, directories 755: the state you actually wanted
```
Note
It succeeded and broke the tree. chmod did exactly what it was told; the problem is that 644 is a sensible mode for a file and a useless one for a directory, and -R applies it to both.

Even find could not recover - the second error is Failed to restore initial working directory, because the process could not get back into a directory it had no execute bit on.

The fix is two commands: 755 on the directories, 644 on the files. Which is exactly what capital X does in one.

Expected resultexit 0, then ls: cannot open file '.' and find: '.': Permission denied - and after putting 755 back on the directories, everything works again.

Success conditionYou know the mistake before you make it.
Capital X, which exists for this
A tree where nothing has execute, then a+X.
bash Example session
```
$cd ~/ess/x && chmod -R a-x . 2>/dev/null; sudo chmod 700 . sub; chmod 600 f sub/g; stat -c '%A %n' . sub f sub/gdrwx------ .drwx------ sub-rw------- f-rw------- sub/g$cd ~/ess/x && chmod -R a+X . && stat -c '%A %n' . sub f sub/g; echo "--- +X gave x to the DIRECTORIES and left the files alone"drwx--x--x .drwx--x--x sub-rw------- f-rw------- sub/g--- +X gave x to the DIRECTORIES and left the files alone$cd ~/ess/x && chmod u+x f && chmod -R a+X . && stat -c '%A %n' f; echo "--- but f already had one x, so +X handed it the other two as well"-rwx--x--x f--- but f already had one x, so +X handed it the other two as well
```
Note
X means "execute, but only where it makes sense" - on a directory always, and on a file only if it already had an execute bit somewhere. So chmod -R u=rwX,go=rX is the safe way to normalise a tree.

The second half is the part people get wrong. X is not "directories only". Once f had one execute bit, a+X handed it the other two - which for a tree containing a few scripts is usually fine and is occasionally a surprise.

find -type d -exec chmod 755 {} + and find -type f -exec chmod 644 {} + is the explicit alternative, and it is easier to explain in a change ticket.

Expected resultDirectories becoming drwx--x--x while the files stay -rw-------; then a file that already had u+x getting -rwx--x--x.

Success conditionYou can fix a tree's modes in one command.
The three bits above the nine
setuid on a real binary, setgid on a shared directory, and the sticky bit on /tmp.
bash Example session
```
$cd ~/ess/perm && ls -l /usr/bin/passwd /usr/bin/wall /tmp -d 2>/dev/null | awk '{print $1, $3, $4, $NF}'drwxrwxrwt root root /tmp-rwsr-xr-x root root /usr/bin/passwd-rwxr-xr-x root root /usr/bin/wall$cd ~/ess/perm && mkdir -p shared && sudo chgrp sudo shared && sudo chmod 2775 shared && stat -c '%A %a %U:%G %n' shared; echo "--- setgid: new files inherit the directory group"drwxrwsr-x 2775 sysadmin:sudo shared--- setgid: new files inherit the directory group$cd ~/ess/perm && touch shared/mine && stat -c '%U:%G %n' shared/mine; echo "--- compare a normal directory:"; touch newdir/mine && stat -c '%U:%G %n' newdir/minesysadmin:sudo shared/mine--- compare a normal directory:sysadmin:sysadmin newdir/mine$cd ~/ess/perm && mkdir -p stick && chmod 1777 stick && stat -c '%A %a %n' stick; echo "--- the t is the sticky bit: only the owner of a file may delete it"drwxrwxrwt 1777 stick--- the t is the sticky bit: only the owner of a file may delete it
```
Note
setuid is the s in the owner's execute position - passwd runs as root so it can write /etc/shadow. It is the reason that binary is audited so heavily, and setuid on a shell script is ignored by Linux for exactly that reason.

setgid on a directory is the useful one, and the capture proves it: a file created inside inherits the directory's group instead of the creator's primary group. That is how a shared project directory works, and 2775 is the mode to remember.

The sticky bit t on /tmp means only a file's owner may delete it, even though the directory is world-writable. Without it, any user could delete anyone's temporary files.

A capital S or T instead of lower case means the bit is set and the underlying execute bit is not - almost always a mistake.

Expected result-rwsr-xr-x on /usr/bin/passwd, drwxrwxrwt on /tmp; then setgid drwxrwsr-x 2775 making a new file sysadmin:sudo where a normal directory gives sysadmin:sysadmin.

Success conditionYou can read and set the special bits.
Owner and group, and what changing the owner does not do
chown in its three forms - and then a write that should have failed.
bash Example session
```
$cd ~/ess/perm && sudo chown root newfile && stat -c '%U:%G %n' newfile; sudo chown root:sudo newfile && stat -c '%U:%G %n' newfile; sudo chgrp sysadmin newfile && stat -c '%U:%G %n' newfileroot:sysadmin newfileroot:sudo newfileroot:sysadmin newfile$cd ~/ess/perm && sudo chown -R sysadmin:sysadmin tree && find tree -exec stat -c '%U:%G %n' {} \;sysadmin:sysadmin treesysadmin:sysadmin tree/subsysadmin:sysadmin tree/sub/gsysadmin:sysadmin tree/f
```
Note
Three forms: chown user, chown user:group, chgrp group. chown user: uses the user's primary group, which saves looking it up.

Only root can give a file away. A normal user cannot chown their own file to someone else - that would let them dodge a disk quota - and can only chgrp to a group they belong to.

-R follows the tree but not symlinks by default; -h acts on the link itself and -L follows them. On a tree containing symlinks out of it, the difference matters.

Expected resultroot:sysadmin, then root:sudo, then root:sysadmin again; and -R applying to the whole tree.

Success conditionYou can change ownership precisely.
And changing the owner does not take the group's access away
A file handed to root, still written by a normal user.
zsh Example session
```
$cd ~/ess/own && sudo chown root f && stat -c '%A %U:%G %n' f; echo "test" > f && echo "the write SUCCEEDED - group sysadmin still has w, and I am in it"; stat -c '%s bytes' f-rw-rw-r-- root:sysadmin fthe write SUCCEEDED - group sysadmin still has w, and I am in it5 bytes$cd ~/ess/own && sudo chown root:root f && stat -c '%A %U:%G %n' f; echo "test" > f 2>&1 | tail -1; echo "--- now the group is root too, and only o=r applies"-rw-rw-r-- root:root fzsh:2: permission denied: f--- now the group is root too, and only o=r applies
```
Note
The write succeeded because the group was still mine. The kernel checks owner, then group, then other, and stops at the first that applies - so being in the file's group with g+w is enough, whoever owns it.

Which makes chown root somefile a weaker protection than it looks. Securing a file means the mode *and* the ownership: chown root:root and chmod 600.

Once the group was root too, only other applied - r-- - and the write was refused. That is the same three-step check, landing one step further along.

Expected resultAfter chown root: mode still -rw-rw-r--, group still sysadmin, and the write succeeds. After chown root:root: permission denied.

Success conditionYou can reason about which of the three sets applies to you.
ACLs, for when nine bits are not enough
The tools are not installed on Ubuntu, so first install them.
bash Example session
```
$command -v getfacl setfacl 2>/dev/null || echo "not installed yet"; sudo apt-get install -y -qq acl 2>&1 | tail -2; command -v getfacl setfaclnot installed yet No VM guests are running outdated hypervisor (qemu) binaries on this host./usr/bin/getfacl/usr/bin/setfacl$mkdir -p ~/ess/acl && cd ~/ess/acl && touch f && getfacl f 2>&1# file: f# owner: sysadmin# group: sysadminuser::rw-group::rw-other::r--$cd ~/ess/acl && setfacl -m u:nobody:rw f && getfacl f 2>&1 | tail -7# group: sysadminuser::rw-user:nobody:rw-group::rw-mask::rw-other::r--$cd ~/ess/acl && mkdir d && setfacl -d -m g:sudo:rwx d && touch d/inherited && getfacl d/inherited 2>&1 | tail -6; echo "--- a DEFAULT acl is inherited by new files"user::rw-group::rwx	#effective:rw-group:sudo:rwx	#effective:rw-mask::rw-other::r-- --- a DEFAULT acl is inherited by new files
```
Note
Not installed on Ubuntu 26.04, installed on RHEL 10 - the capture shows acl-2.3.2 present there. Another thing to check before the clock starts.

An ACL is how you say "and also this one user" without inventing a group. setfacl -m u:name:rw file is the whole of the common case.

The mask entry is the ceiling. It limits what any named user or group entry can actually get, and chmod g= on an ACL'd file changes the mask rather than the group - which is why the two systems interact confusingly. getfacl prints #effective: when the mask is reducing something.

A DEFAULT ACL (-d) is inherited by new files in that directory, which is the ACL version of setgid and the reason to use one on a shared tree.

Expected resultnot installed yet then the binaries after apt-get install acl; a plain getfacl showing three entries; then a user:nobody:rw- entry and a mask::rw-; and a default ACL inherited by a new file.

Success conditionYou can grant one extra user access to one file.
And the ACL that stays after you remove it
Removing the entry, and then removing the ACL.
bash Example session
```
$cd ~/ess/acl && setfacl -x u:nobody f && ls -l f | awk '{print $1}'; getfacl f 2>/dev/null | tail -5; echo "--- the named entry is gone and the + is STILL THERE - a mask entry remains"-rw-rw-r--+user::rw-group::rw-mask::rw-other::r-- --- the named entry is gone and the + is STILL THERE - a mask entry remains$cd ~/ess/acl && setfacl -b f && ls -l f | awk '{print $1}'; getfacl f 2>/dev/null | tail -4; echo "--- -b removes the whole ACL, and only then does the + go"-rw-rw-r--user::rw-group::rw-other::r-- --- -b removes the whole ACL, and only then does the + go
```
Note
-x removes one entry; the ACL survives. A mask:: entry remains, so the file still has an extended ACL and ls -l still shows the +. I had written that -x clears it, and the transcript said otherwise.

-b removes the whole thing and returns the file to plain nine-bit permissions.

The + in ls -l is the only visible sign, and stat -c '%A' does *not* show it - the earlier capture confirms that. So a file can have an ACL you never notice, which is exactly how a permissions problem becomes unexplainable. If ls -l shows a +, run getfacl.

guide 10 is next.

Expected resultAfter -x: the named entry gone and ls -l still showing -rw-rw-r--+. After -b: the + finally gone.

Success conditionYou can tell whether a file still has an ACL.

Troubleshooting

chmod -R 755 or -R 644 broke a directory tree.

Why: A file mode applied to directories removes their execute bit.

Fix:chmod -R u=rwX,go=rX, or two find -type passes. Put 755 back on the directories first.
ls works in a directory but ls -l fails on every entry.

Why: The directory has r but not x, so names are readable and cannot be stat'ed.

Fix:Add the execute bit: chmod +x thedir.
New files in a shared directory get the wrong group.

Why: The directory is not setgid, so files take the creator's primary group.

Fix:chmod 2775 thedir and fix existing files with chgrp -R.
A permission problem that the mode string does not explain.

Why: There is an ACL. Look for the + in ls -l.

Fix:getfacl file. setfacl -b to clear it.
getfacl: command not found.

Why: The acl package is not installed - the default on Ubuntu 26.04.

Fix:apt-get install acl. RHEL has it already.
A user can still write a file after you chowned it to root.

Why: The group did not change and the group has write.

Fix:chown root:root and chmod 600.
A capital S or T in the mode.

Why: The special bit is set without the underlying execute bit.

Fix:Almost always a mistake - add the execute bit or clear the special bit.

Official sources

← All LFCS guides

Permissions, ownership and the bits above them

This guide includes

Before you start

The mode a new file gets, and the umask that decided it

chmod, both spellings

What execute means on a directory

So chmod -R with a file mode locks you out

Capital X, which exists for this

The three bits above the nine

Owner and group, and what changing the owner does not do

And changing the owner does not take the group's access away

ACLs, for when nine bits are not enough

And the ACL that stays after you remove it

Troubleshooting

Official sources