Linux File Permissions Explained: chmod, chown, and umask Examples

Need to fix access to a file? Start by checking what’s already there with ls -l. Then use chmod to change permissions or chown to correct the ownership.

ls -l report.txt
chmod 640 report.txt
sudo chown alice:developers report.txt

Here, the owner gets read and write access. The group can read the file, everyone else is blocked, and the file is assigned to user alice and group developers.

Warning: Don’t treat chmod 777 as a universal answer to permission errors. It lets every local user modify the affected file or directory, which can create a serious security risk.

Quick commands

These are the usual commands for checking and managing Linux file permissions:

Reading Linux file permissions

Run ls -l and you’ll see the file type, permission bits, owner, and group:

ls -l deploy.sh
-rwxr-x--- 1 alice developers 842 May 10 09:30 deploy.sh

That first character tells you what sort of object you’re looking at. A hyphen marks a regular file, while d means it’s a directory. After that come nine characters, split into permission sets for the user, group, and everyone else.

rwx  r-x  ---
user group others

The same letter can mean something slightly different for a directory than it does for a regular file.

Understanding numeric modes

Numeric permissions give each permission a value. Read is 4, write is 2, and execute is 1. Add the relevant values together for the owner, then do the same for the group and others.

A few modes show up often:

• chmod 600 private.key gives only the owner permission to read and modify the file.
• chmod 644 document.txt lets the owner write to the file, while everyone can read it.
• chmod 700 backup.sh gives only the owner read, write, and execute access.
• chmod 755 script.sh lets the owner modify the file and everyone execute it.

Changing permissions with symbols

Symbolic mode is handy when you need to alter one permission without overwriting everything that’s already set. Use u for the user, g for the group, o for others, and a for everyone.

chmod u+x deploy.sh
chmod g+w shared.txt
chmod o-r secrets.txt
chmod a+r documentation.txt
chmod u=rw,g=r,o= report.txt

The operators are fairly direct. + adds a permission, - removes one, and = sets the permissions exactly.

Correcting ownership with chown and chgrp

If a file belongs to the wrong account or service, use chown. You’ll normally need root privileges to change ownership.

sudo chown alice report.txt
sudo chown alice:developers report.txt
sudo chown :developers report.txt
sudo chgrp developers report.txt

The first command changes the owner and leaves the group alone. The second changes both. In the last two examples, only the group is changed.

Changing ownership recursively

sudo chown -R www-data:www-data /var/www/example

Pause and check the path before adding -R. A recursive ownership change aimed at a system directory can stop services, or even the operating system, from working correctly.

Setting default permissions with umask

umask removes permissions from the default modes that programs use when creating files and directories. Files generally start from mode 666. Directories start from 777.

umask
umask 027

With a mask of 027, new files will normally have mode 640, while directories will have 750. That leaves the owner with full practical access, gives the group limited access, and gives others none.

To make a personal umask apply automatically, add it to the shell startup file used by your distribution, such as ~/.profile:

umask 027

Using separate modes for files and directories

Directories usually need execute permission so users can pass through them. Ordinary documents don’t. So rather than applying one recursive mode to everything, use find to handle each type separately.

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

This gives directories mode 755 and regular files mode 644. It also avoids the common mistake of making every file executable.

Special permission bits

• Setuid (4) makes an executable run with the file owner’s effective privileges.
• Setgid (2) causes new files in a directory to inherit that directory’s group.
• Sticky bit (1) means users can delete only their own files from a shared directory.

sudo chmod 2775 /srv/shared
sudo chmod 1777 /srv/dropbox

Be cautious with setuid. If an executable has elevated privileges and contains a vulnerability, it can become a security risk.

Common errors and access problems

• Using 777 for every permission error. Work out which owner, group, and access level are actually required instead.
• Overlooking parent directory permissions. A user needs execute permission on every parent directory in the path.
• Making ordinary documents executable. Apply different recursive rules to files and directories.
• Ignoring ACLs. Access control lists may grant permissions that don’t appear in the standard nine-character mode.
• Running a recursive command from the wrong location. Check the target with pwd and ls first.

Sometimes the displayed permissions look right and access still fails. In that case, inspect every component of the path, then check for ACL entries too.

namei -l /srv/site/private/report.txt
getfacl /srv/site/private/report.txt

Checking the result

After changing a file or directory, inspect it again with ls -ld. stat gives you another view of the same target.

ls -ld /srv/shared
stat /srv/shared

For a more definite test, run a harmless command as the account that’s supposed to have access:

sudo -u alice test -w /srv/shared && echo Writable
sudo -u alice test -x /srv/shared && echo Accessible

That checks the user’s effective access instead of relying only on the permission bits shown on screen.