Hands-on Lab·Red Hat Certified System Administrator

Linux File and Directory Permissions

chmod syntax takes ten minutes to learn. What rwx means on a *directory* is what people get wrong for years, so it is tested here as a real second user: r without x, x without r, and the fact that deleting a file depends on the directory's permissions rather than the file's.

Essential Tools Guide 8 of 67 Beginner

OSRHEL 10.0 (Coughlan)
Kernel6.12.0-55.9.1.el10_0
dnf4.20.0
Flatpak1.16.0
TimeAbout 16 min
Reviewed23 August 2026

Written against the versions above. The trailing `.` in `-rw-r--r--.` is the SELinux context indicator, not a permission. A `+` in that position means an ACL is present. Both appear throughout this path.

Every command on this page runs on RHCSA-A01.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
RHCSA-A01	192.168.0.31	RHEL 10.0 (Coughlan)	Practice node (graded) - spare /dev/sda	2 Core	4 GB	50 GB + 15 GB

Before you start

A sudo-capable account.
The session creates a permtest user and a permgrp group, and removes both.

Reading the ten characters
```
-rw-r--r--. 1 sysadmin sysadmin 6 Aug 23 10:55 file.txt
```
One character of type, then three groups of three: owner, group, everyone else. Here the owner may read and write, group and others may only read.

stat says the same thing without the counting:
```
-rw-r--r-- 644 sysadmin sysadmin file.txt
```
%A is the symbolic form and %a the octal, side by side - which is the fastest way to learn to convert between them. r=4, w=2, x=1, added per group: rw- is 6, r-- is 4, so 644.

A directory shows d first and typically 755. Keep that pairing in mind - 644 for files and 755 for directories are the defaults almost everything expects, and the reason why is the last two steps of this guide.
bash Example session
```
$mkdir -p ~/perm && cd ~/perm && echo hello > file.txt && ls -l file.txt-rw-r--r--. 1 sysadmin sysadmin 6 Aug 23 10:55 file.txt$cd ~/perm && stat -c '%A %a %U %G %n' file.txt-rw-r--r-- 644 sysadmin sysadmin file.txt$cd ~/perm && ls -ld . && stat -c '%A %a' .drwxr-xr-x. 2 sysadmin sysadmin 22 Aug 23 10:55 .drwxr-xr-x 755
```
Expected resultThe same permissions in symbolic and octal form.

Success conditionYou can convert between rw-r--r-- and 644 without thinking.
Two ways to set them
Symbolic changes only what you name:
```
-rw-r-----. 1 sysadmin sysadmin 6 ... file.txt
```
u=rw,g=r,o= sets each class explicitly; g+w,o+r adds without disturbing the rest; a-x,u+x removes from everyone then adds back for the owner. The + and - forms are the ones to reach for when you must not disturb bits you were not asked about.

Octal replaces all nine at once:
```
-rw-r----- 640
```
640 is unambiguous and fast, and it overwrites everything - including bits that were deliberately set. On an exam task phrased as "the file must be 0640", octal is correct and quicker. On "give the group write access", g+w is correct and octal risks clearing something.

A detail worth carrying: chmod never touches ownership and chown never touches permissions. Tasks usually need both.
bash Example session
```
$cd ~/perm && chmod u=rw,g=r,o= file.txt && ls -l file.txt-rw-r-----. 1 sysadmin sysadmin 6 Aug 23 10:55 file.txt$cd ~/perm && chmod 640 file.txt && ls -l file.txt-rw-r-----. 1 sysadmin sysadmin 6 Aug 23 10:55 file.txt$cd ~/perm && chmod g+w,o+r file.txt && stat -c '%A %a' file.txt-rw-rw-r-- 664$cd ~/perm && chmod a-x,u+x file.txt && stat -c '%A %a' file.txt-rwxrw-r-- 764
```
Expected resultThe same file walked through four permission sets.

Success conditionYou can choose symbolic or octal for the right reason.
Ownership
```
uid=1001(permtest) gid=1001(permtest) groups=1001(permtest)
```
chown sets the owner, chgrp the group, and chown user:group does both in one command:
```
-rw-rw-r--. 1 permtest sysadmin  6 ... file.txt
-rw-rw-r--. 1 permtest permgrp   6 ... file.txt
```
Only root can give a file away. A normal user cannot chown a file they own to someone else - otherwise disk quotas would mean nothing. Changing the *group* is allowed if you own the file and belong to the target group.

chown -R recurses, and is the usual way an exam task about a shared directory is answered. Be careful with it: chown -R following a symlink out of the tree is a classic way to change ownership of things you did not intend, which is why -h and --no-dereference exist.
bash Example session
```
$sudo useradd -m permtest 2>/dev/null; sudo groupadd -f permgrp; id permtestuid=1001(permtest) gid=1001(permtest) groups=1001(permtest)$cd ~/perm && sudo chown permtest file.txt && ls -l file.txt-rw-r--r--. 1 permtest sysadmin 6 Aug 23 10:55 file.txt$cd ~/perm && sudo chgrp permgrp file.txt && ls -l file.txt-rw-r--r--. 1 permtest permgrp 6 Aug 23 10:55 file.txt$cd ~/perm && sudo chown sysadmin:sysadmin file.txt && ls -l file.txt-rw-r--r--. 1 sysadmin sysadmin 6 Aug 23 10:55 file.txt
```
Expected resultOwner and group changed independently, then together.

Success conditionYou can set both halves of ownership.

r and x on a directory are not what they look like

A directory d containing inside.txt, and a second user trying to reach it.

744 - read but no execute:

inside.txt
exit=0 - r lets you LIST names

cat: d/inside.txt: Permission denied
exit=1 - but r alone does not let you reach the file

They can see that inside.txt exists and cannot open it. r grants the list of names, nothing more.

711 - execute but no read:

ls: cannot open directory 'd': Permission denied
exit=2 - x without r: cannot list

secret
exit=0 - but CAN read a file whose name you already know

The exact opposite. They cannot discover what is in the directory, but naming the file directly works. x grants the right to traverse - to use the directory as part of a path.

That is why 711 on a home directory is a real pattern: others can reach ~/public_html/index.html without being able to enumerate what else is in your home. And it is why a missing x anywhere along a path denies access to everything below it, however open the file itself is.

bash Example session

$cd ~/perm && sudo chmod 744 d && sudo -u permtest ls d 2>&1; echo "exit=$? - r lets you LIST names"inside.txtexit=0 - r lets you LIST names$cd ~/perm && sudo -u permtest cat d/inside.txt 2>&1; echo "exit=$? - but r alone does not let you reach the file"cat: d/inside.txt: Permission deniedexit=1 - but r alone does not let you reach the file$cd ~/perm && sudo chmod 711 d && sudo -u permtest ls d 2>&1; echo "exit=$? - x without r: cannot list"ls: cannot open directory 'd': Permission deniedexit=2 - x without r: cannot list$cd ~/perm && sudo chmod 644 d/inside.txt && sudo -u permtest cat d/inside.txt 2>&1; echo "exit=$? - but CAN read a file whose name you already know"secretexit=0 - but CAN read a file whose name you already know

Expected resultList-without-read, then read-without-list.

Success conditionYou can diagnose a permission failure that is three directories up the path.

Deleting depends on the directory, not the file
A file set to 444 - read-only for everybody - inside a directory the user cannot write:
```
rm: cannot remove 'd/inside.txt': Permission denied
exit=1 - deleting needs w on the DIRECTORY, not the file
```
Now make the directory writable and change nothing about the file:
```
the read-only file was removed because the directory was writable
```
A read-only file was deleted by a user who could not write to it. Deleting is removing a name from a directory, so it is the *directory's* w bit that governs it. The file's permissions are irrelevant.

This is the single most surprising rule in Unix permissions, and it is why /tmp is 1777 rather than 777. That leading 1 is the sticky bit, which adds the exception: in a sticky directory you may only delete what you own. Without it, any user could delete any other user's files in /tmp - and guide 42 takes that apart.
bash Example session
```
$cd ~/perm && sudo chmod 755 d && sudo chmod 444 d/inside.txt && sudo -u permtest rm -f d/inside.txt 2>&1 | head -2; echo "exit=$? - deleting needs w on the DIRECTORY, not the file"rm: cannot remove 'd/inside.txt': Permission deniedexit=0 - deleting needs w on the DIRECTORY, not the file$cd ~/perm && sudo chmod 777 d && sudo -u permtest rm -f d/inside.txt && ls d; echo "the read-only file was removed because the directory was writable"the read-only file was removed because the directory was writable
```
Expected resultA read-only file surviving, then being deleted, with no change to the file.

Success conditionYou know which permission actually controls deletion.

Troubleshooting

Permission denied on a file whose permissions look correct.

Why: A directory in the path is missing x for you.

Fix:namei -l /full/path/to/file prints the permissions of every component.
A user can delete a file they cannot write.

Why: They have write on the containing directory.

Fix:Expected behaviour. Add the sticky bit - chmod +t - to restrict deletion to owners.
chown as a normal user says "Operation not permitted".

Why: Only root can give a file to another user.

Fix:Use sudo. Changing group is allowed if you own the file and are in that group.
A new group membership has no effect.

Why: Group membership is read at login.

Fix:Log out and in, or newgrp <group> for the current shell. Verify with id.

Official sources

← All RHCSA guides

Linux File and Directory Permissions

Before you start

Reading the ten characters

Two ways to set them

Ownership

r and x on a directory are not what they look like

Deleting depends on the directory, not the file

Troubleshooting

Official sources