Linux file permissions: chmod, chown and umask explained

Reading ls -l

ls -l shows the permissions in the first column:

-rw-r--r-- 1 alice alice   220 Sep 27 10:12 notes.txt
-rwxr-xr-x 1 alice alice  1408 Sep 27 10:15 backup.sh
drwxr-x--- 2 alice media  4096 Sep 27 10:20 photos

Split the first ten characters into four parts:

On a file, r reads the content, w changes it and x runs it. On a directory, r lists the names, w creates and deletes files in it, and x lets you enter it at all. Deleting a file is a right on the directory, not on the file. stat -c '%a %A %U:%G' file prints the octal mode, the symbolic mode and the owner in one line.

chmod: octal and symbolic

Octal sets all three classes at once. Add up read (4), write (2) and execute (1) per class: 6 is read and write, 5 is read and execute, 7 is everything.

Symbolic changes only what you name: u (user, the owner), g (group), o (others), a (all), with +, - or =. Separate several changes with a comma and no space:

chmod 600 ~/.config/rclone/rclone.conf   # owner only
chmod u+x backup.sh                      # add execute for the owner
chmod g+w,o-rwx shared.txt               # group may write, others get nothing
chmod u=rwx,go=r script.sh               # exactly rwxr--r--
chmod -R u+rwX,go-rwx ~/private          # capital X: execute only on directories

The chmod calculator converts between the two forms and explains every bit. The reference is chmod(1).

chown and groups

Only root may give a file to another user, so chown usually needs sudo. The form is user:group; leave out either side to keep it.

sudo chown alice notes.txt              # new owner, group unchanged
sudo chown alice:media /srv/media       # owner and group
sudo chown :media /srv/media/film.mkv   # group only (same as chgrp media)
sudo chown -R alice:media /srv/media    # the whole tree

Groups are how you share without opening things to everyone: put the users that need access in one group, give the directory to that group, and set 750 or 770. Adding users to groups is covered in users, groups and sudo.

umask: the default for new files

New files start at 666 and new directories at 777, minus the bits in your umask. The common default umask 022 removes write for group and others, so new files are 644 and new directories 755. Run umask to see yours.

umask            # 0022
umask 027        # this shell only: new files 640, new directories 750
touch a.txt; mkdir d; stat -c '%a %n' a.txt d
# 640 a.txt
# 750 d

The same with the default umask, then chmod in both notations, run in an empty directory:

$ umask; touch notes.txt; mkdir share; ls -ld notes.txt share
0022
-rw-r--r-- 1 user user 0 Sep 28 06:29 notes.txt
drwxr-xr-x 1 user user 0 Sep 28 06:29 share

$ chmod 640 notes.txt; chmod u=rwx,g=rx,o= share; stat -c '%A  %a  %n' notes.txt share
-rw-r-----  640  notes.txt
drwxr-x---  750  share

For a systemd service, set UMask=0027 in its unit instead of changing the shell.

setgid and the sticky bit

• setgid on a directory (chmod g+s dir, or a leading 2 as in 2775): new files inside get the directory's group instead of the creator's. Ideal for a shared /srv/media.
• Sticky bit (chmod +t dir, a leading 1): in a directory everyone may write to, only the owner of a file may delete it. /tmp is drwxrwxrwt, which is 1777.
• setuid (a leading 4) runs a program as its owner. It belongs to a handful of system programs such as passwd; never set it on a script.

Both on the share directory from above (mode 750). The group's x turns into s. Others have no x, so the sticky bit shows as a capital T instead of t, and the leading digit becomes 3 (2 for setgid plus 1 for sticky):

$ chmod g+s share; chmod +t share; ls -ld share; stat -c '%A %a' share
drwxr-s--T 1 user user 0 Sep 28 06:29 share
drwxr-s--T 3750

Permissions and rootless containers

Rootless podman maps users inside the container to other numbers outside it. Root in the container is your own user on the host; user 1000 in the container becomes a number from your range in /etc/subuid, such as 100999. That is why files in a bind-mounted directory sometimes show an owner you have never heard of.

To fix ownership from the container's point of view, run the command inside your user namespace, podman unshare chown 1000:1000 ~/appdata, or add the :U option to the volume (Volume=%h/appdata:/data:U in a quadlet) and podman chowns it for you.

Here is the mapping in action: a file handed to user 1000 inside the namespace belongs to 100999 on the host (the subuid range starts at 100000, and container UID 1 maps to 100000):

$ touch owned-by-container
$ podman unshare chown 1000:1000 owned-by-container
$ ls -ln owned-by-container
-rw-r--r-- 1 100999 100999 0 Sep 28 06:37 owned-by-container
$ podman unshare ls -ln owned-by-container
-rw-r--r-- 1 1000 1000 0 Sep 28 06:37 owned-by-container

Common mistakes

Frequently asked questions