Linux File Permissions: chmod, chown and sudo with Examples

Linux file permissions answer the question "who can do what with a file". Every file has an owner, a group and three sets of permissions: for the owner, for the group and for everyone else. Permissions are changed with chmod, the owner with chown, and administrator actions are run with sudo. Let's look at how to read permissions, how to change them and how to fix the Permission denied error.

How to see a file's permissions

Permissions are shown in the output of ls -l:

$ ls -l
-rw-r--r-- 1 alice developers  1204 Oct 10 14:02 notes.txt
-rwxr-xr-x 1 alice developers   356 Oct 10 14:05 deploy.sh
drwxr-x--- 2 alice developers  4096 Oct 10 13:50 secrets

The first ten characters are read like this:

• The first character is the type: - a regular file, d a directory, l a symbolic link.
• Characters 2–4 are the owner's permissions (user).
• Characters 5–7 are the group's permissions (group).
• Characters 8–10 are the permissions for others.

Next come the number of hard links, the owner (alice), the group (developers), the size, the date and the name. For a single file the stat command is handy:

$ stat -c '%A %a %U:%G %n' deploy.sh
-rwxr-xr-x 755 alice:developers deploy.sh

What r, w and x mean

The meaning of permissions differs for files and directories — this is the main source of confusion.

Note: you can delete a file if you have w and x on the directory, even if you are not allowed to write to the file itself. And without x on a directory you cannot open a file inside it, even if the file's permissions allow reading.

The system checks permissions in order: if you are the owner, the owner's permissions apply; otherwise, if you are in the file's group, the group's permissions apply; otherwise, the permissions for others apply. The root user bypasses read and write checks.

Numeric form: 755, 644, 600

Each permission has a weight: r = 4, w = 2, x = 1. The sum of the weights gives a digit from 0 to 7 for each of the three sets.

Typical sets worth knowing by heart:

The chmod command: changing permissions

Numeric mode

The numeric form sets the permissions in full:

chmod 644 index.html
chmod 755 deploy.sh
chmod 600 ~/.ssh/id_ed25519

Symbolic mode

The symbolic form changes permissions precisely, leaving the others untouched. Who: u owner, g group, o others, a all. Action: + add, - remove, = set exactly.

chmod +x deploy.sh        # allow running
chmod u+x,g-w file        # owner can run, remove write from group
chmod o-rwx secrets/      # nothing for others
chmod g=rx app/           # group gets exactly read and enter

Recursively: files and directories differently

The -R flag applies permissions to the whole tree. But chmod -R 755 makes every file executable, which is usually not wanted. It is better to separate files and directories with find:

find /srv/site -type d -exec chmod 755 {} +
find /srv/site -type f -exec chmod 644 {} +

There is also a short variant: a capital X adds execute permission only to directories and to files that already have it.

chmod -R u=rwX,go=rX /srv/site

The chown command: changing owner and group

Only root can change a file's owner, so chown is almost always run with sudo.

sudo chown alice report.txt               # owner
sudo chown alice:developers report.txt    # owner and group
sudo chown :www-data index.html           # group only
sudo chown -R www-data:www-data /var/www/site

To change only the group there is a separate command, chgrp: sudo chgrp developers report.txt. Your groups are shown by id or groups.

$ id
uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),1001(developers)

To add a user to a group, use sudo usermod -aG developers bob. The -a flag is required: without it the user is removed from all other supplementary groups. A new group takes effect after the user logs in again.

sudo: actions as the administrator

sudo runs one command with root privileges (or another user's) and asks for your own password, not the root password. Every call is written to the log, so it is visible who did what.

sudo apt update
sudo systemctl restart nginx
sudo -u postgres psql       # as the postgres user
sudo -i                     # interactive root shell
sudo -l                     # what I am allowed to do

Who is allowed to do what is described in /etc/sudoers and in the files of the /etc/sudoers.d/ directory. Edit them only with sudo visudo: it checks the syntax, and a mistake in the file will not lock you out of sudo. On Ubuntu sudo rights are granted by membership in the sudo group, on RHEL-like systems in the wheel group.

# /etc/sudoers.d/deploy — user deploy may only restart nginx
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Why sudo echo > file does not work

A common trap:

$ sudo echo "127.0.0.1 test.local" >> /etc/hosts
bash: /etc/hosts: Permission denied

The redirection >> is performed by your shell, not by sudo, so the file is opened without root rights. The correct way is through tee:

echo "127.0.0.1 test.local" | sudo tee -a /etc/hosts

Permission denied: causes and fixes

The Permission denied error means the kernel refused your process the operation. The troubleshooting algorithm is always the same: who am I (id), who is the owner and what are the permissions (ls -l), what are the permissions on each directory in the path (namei -l).

$ namei -l /srv/app/config/app.env
f: /srv/app/config/app.env
drwxr-xr-x root  root  /
drwxr-xr-x root  root  srv
drwxr-x--- deploy deploy app
drwxr-xr-x deploy deploy config
-rw-r----- deploy deploy app.env

Here the app directory is closed to others — a user who is not in the deploy group cannot get any further, whatever the permissions on the file itself.

The script does not run

$ ./deploy.sh
bash: ./deploy.sh: Permission denied

The file has no execute permission. The fix is chmod +x deploy.sh, or running it through the interpreter: bash deploy.sh. If the partition is mounted with the noexec option (this happens with /tmp), you cannot run the file directly, and only the second option helps.

Cannot write to a system directory

Files in /etc, /usr and /var/www belong to root or to service users. Use sudo for one-off edits, and for ongoing work give rights to a group rather than to everyone.

The web server returns 403

Nginx or Apache run as the www-data user (on Debian and Ubuntu). It needs read access to the files and x on all directories in the path. The fix: sudo chown -R www-data:www-data /var/www/site, or permissions 755 on directories and 644 on files.

SSH does not accept the key

SSH refuses keys whose permissions are too open. The private key must have 600 permissions, the ~/.ssh directory — 700, and the authorized_keys file on the server — 600.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

No access to Docker

The message permission denied while trying to connect to the Docker daemon socket means you are not in the docker group. Run sudo usermod -aG docker $USER and log in again. Keep in mind that membership in this group is effectively equal to root rights.

Why chmod 777 is a bad idea

The advice "just run chmod 777" removes the error but makes the file writable by every user and every process on the system. If a web application is compromised, an attacker can replace such files. The right path is to find out which user needs access and grant the right to exactly that user — through the owner or the group.

umask: default permissions

New files get permissions based on the umask mask. With the typical value 022, files are created with 644 permissions and directories with 755.

$ umask
0022

Summary

Linux file permissions are three sets of rwx for the owner, the group and others. chmod changes permissions in numeric (755, 644, 600) or symbolic form, chown changes the owner, and sudo lets you run a single command as root. When you get Permission denied, check the user, the permissions on the file and on every directory in the path, and do not fix the problem with 777. Users, groups, permissions and sudo are covered step by step in our Linux course.