File permissions in Linux

Q: Permission denied when running a script

The x bit is missing: chmod +x script.sh. Or the file is on a noexec partition (mount | grep noexec, see mount). Or the shebang is wrong.

Q: The web server can't read files (403)

nginx runs as www-data — it needs r on the files and x on every directory along the path. namei -l /var/www/site/index.html shows exactly where the permission is missing.

Q: Access should work, but it doesn't

ACLs may be in play (a + in ls -l), or AppArmor (look for apparmor ... DENIED in the journal). Classic permissions alone don't tell the whole story.

Overview

Every file has an owner, a group, and three sets of permissions: for the owner (u), the group (g), and everyone else (o). The permissions are: r (read), w (write), x (execute; for a directory — enter/traverse).

-rwxr-x---  1 alice devs  ...
 │└┬┘└┬┘└┬┘     │     └ group
 │ u  g  o      └ owner
 └ type (- file, d directory, l link)

Numeric notation: r=4, w=2, x=1. 750 = rwx r-x ---. More on changing permissions — chmod-chown.

Recipes

2

Numbers and symbols

Octal	Permissions	Typically for
`644`	rw-r--r--	regular files
`600`	rw-------	secrets, keys
`755`	rwxr-xr-x	scripts, binaries, directories
`700`	rwx------	private directories
`775`	rwxrwxr-x	a shared group directory
`1777`	rwxrwxrwt	shared with sticky (like /tmp)

bash

ls -l file                        # show permissions/owner
chmod 640 file                    # u=rw g=r o=
chmod u+x,go-w file               # symbolic: +x for owner, remove w from g/o
chmod -R u+rwX dir                # recursive; X = x only for directories/already-executable files
umask                             # the mask for new files (022 → files 644, directories 755)

Special bits

The three special bits and a team's shared directory are covered in Special permission bits.

Bit	On a file	On a directory	Set with
SUID (4xxx)	runs with the file owner's permissions	—	`chmod u+s`
SGID (2xxx)	runs with the group's permissions	new files inherit the directory's group	`chmod g+s`
sticky (1xxx)	—	only the file's owner can delete it (like `/tmp`)	`chmod +t`

bash

ls -l /usr/bin/passwd             # -rwsr-xr-x  ← s = SUID
ls -ld /tmp                       # drwxrwxrwt  ← t = sticky
chmod 2775 /shared                # SGID: a shared directory, files inherit its group
find / -perm -4000 -type f 2>/dev/null   # audit every SUID binary (security)

Troubleshooting

5

Permission denied when running a script

The x bit is missing: chmod +x script.sh. Or the file is on a noexec partition (mount | grep noexec, see mount). Or the shebang is wrong.

Can't write to a directory, even though you have w on the file

Creating/deleting/renaming a file depends on permissions on the directory (w+x), not on the file itself. Conversely, you can delete a file with no permissions on it at all, as long as you have w on the directory.

The web server can't read files (403)

nginx runs as www-data — it needs r on the files and x on every directory along the path. namei -l /var/www/site/index.html shows exactly where the permission is missing.

Access should work, but it doesn't

ACLs may be in play (a + in ls -l), or AppArmor (look for apparmor ... DENIED in the journal). Classic permissions alone don't tell the whole story.

An SGID directory: new files have the wrong group

SGID sets the group for new files, but existing ones and files moved in with mv need chgrp -R by hand. Group write access comes from the creator's umask — see Special permission bits.

Danger zone

Danger. chmod -R on system directories (/, /etc, /usr, /var) breaks the permissions that booting and services depend on — for example, the SSH daemon refuses to start if its keys and configs are too open. Scope -R to a specific subtree and check it before restarting anything (ls -ld, namei -l), rather than running it "wider, just in case".

A SUID bit on a binary that can be manipulated in any way (through --help, reading files, or writing) hands a local user code execution with the file owner's permissions. Don't set chmod u+s on scripts and homemade binaries without a clear reason and a review of possible privilege-escalation paths.

Terms

2

file permissions: The r, w, and x bits for the owner, group, and others, stored in the file's inode. On a directory, r allows listing names, w together with x allows creating and removing entries, and x allows accessing files inside. Changed with chmod. Also appears in: Unix sockets, AppArmor, Capabilities: root split into parts, chmod / chown and 6 more
file owner: The user (UID) and group (GID) recorded in a file's inode; the kernel uses them to choose which permission set applies. Changed with chown and chgrp. Also appears in: /proc: processes and the kernel as files, Special permission bits: setuid, setgid, sticky

File permissions

Cheat sheet