Linux File Permissions Explained: Owners, Groups, and Others

How Linux Permissions Work

Every file and directory on a Linux system has an owner, a group, and a set of permission bits. These three elements together determine who can do what with that file. The system checks permissions in a strict order: first the owner, then the group, then others. As soon as a matching rule is found, the check stops.

This means that even if "others" have full access, the owner's permissions take priority. A file owned by root with mode 700 is inaccessible to everyone else, regardless of group or other permissions.

The Three User Classes

Owner (User)

The owner is typically the account that created the file. The owner can change the file's permissions and ownership (with chown). Only root can change ownership to another user.

Check ownership with:

ls -l /etc/passwd
# -rw-r--r-- 1 root root 2847 May 28 10:00 /etc/passwd
#              ^^^^  ^^^^
#              owner group

Group

Every file belongs to one group. Users who are members of that group receive the group-level permissions. This is useful for collaboration — you can give a team read-write access to shared files without opening them to everyone.

Add a user to a group:

sudo usermod -aG developers alice

After adding a user to a group, they must log in again for the change to take effect on existing sessions.

Others

Others means everyone who is neither the owner nor in the file's group. This is the most restrictive category by default. Public web files, for example, give others read access so the web server can serve them.

File vs Directory Permissions

The same permission bits have different effects depending on whether the target is a file or a directory. This is a common source of confusion.

Key insight: read on a directory lets you list names, but without execute you cannot cd into it or access the files' metadata. Execute on a directory is almost always needed alongside read for practical use.

Conversely, execute without read lets you access a file inside the directory if you know its exact name, but you cannot list the directory contents.

Viewing Permissions

The ls -l command shows permissions as a 10-character string:

-rwxr-xr-- 1 alice developers 4096 May 28 10:00 report.txt

Breaking down -rwxr-xr--:

For a comprehensive view including ACLs:

getfacl report.txt

Special Permission Bits

Beyond the standard rwx bits, Linux supports three special permissions that change behavior in specific ways.

setuid (4xxx)

When set on an executable, the program runs as the file's owner, not as the user who launched it.

# The passwd command runs as root regardless of who calls it
ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root root 68208 May 28 10:00 /usr/bin/passwd
#   ^
#   setuid bit (s replaces x)

Setting setuid:

chmod u+s /usr/local/bin/myapp
# Or numerically:
chmod 4755 /usr/local/bin/myapp

Security risk: setuid binaries owned by root are a common privilege escalation target. Audit them regularly.

setgid (2xxx)

On an executable, it runs with the file's group. On a directory, new files inside inherit the directory's group instead of the creator's primary group.

# Shared project directory — all new files get the developers group
chmod g+s /projects/webapp
# Numerically:
chmod 2775 /projects/webapp

setgid on directories is extremely useful for shared workspaces. Without it, new files default to the creator's group, breaking collaboration.

Sticky Bit (1xxx)

On a directory, the sticky bit prevents users from deleting files they do not own. This is essential for shared writable directories like /tmp.

ls -ld /tmp
# drwxrwxrwt 10 root root 4096 May 28 10:00 /tmp
#            ^
#            sticky bit (t replaces x)

Setting the sticky bit:

chmod +t /shared/uploads
# Numerically:
chmod 1777 /shared/uploads

Special Bits Summary

Understanding umask

The umask controls default permissions for newly created files and directories. It subtracts bits from the system defaults (777 for directories, 666 for files).

Common umask values:

Check your current umask:

umask
# 0022

Set umask temporarily:

umask 027

Set it permanently by adding the command to ~/.bashrc or /etc/profile.

Important: umask does not affect files you copy (cp preserves source permissions by default). Use cp --no-preserve=mode to apply umask.

Permission Troubleshooting

"Permission denied" when running a script

# Check if execute bit is set
ls -l script.sh
# Fix:
chmod +x script.sh

Cannot cd into a directory

The directory likely lacks the execute bit for your user class.

# Fix:
chmod o+x /shared/project

Web server returns 403 Forbidden

The web server user (often www-data or nginx) needs read access to files and read+execute on directories.

# Common fix for web roots:
find /var/www -type d -exec chmod 755 {} +
find /var/www -type f -exec chmod 644 {} +

New files have wrong group

The directory probably lacks the setgid bit.

chmod g+s /shared/project

Changes not taking effect

If you added a user to a group but they still lack access, they need to log in again. Group membership is evaluated at login time.

# Quick check without re-login:
sg developers "ls /project"

Key Takeaways

• Linux checks owner, then group, then others — the first match wins
• Execute on directories means "enter," not "run"
• setuid, setgid, and sticky bits extend the basic model for specific scenarios
• Use setgid on shared directories so new files inherit the correct group
• Always set the sticky bit on world-writable directories
• umask subtracts from default permissions — choose 027 or 077 for better security
• When troubleshooting, check the exact user class the process runs as

Try It Yourself

Test different permission combinations and see their effects instantly with our chmod calculator. It handles numeric, symbolic, and special bits — including setuid, setgid, and sticky bit.

Related Guides

• Chmod Guide — syntax and examples for the chmod command itself
• Unix Permissions Reference — quick reference for format conversion, ACLs, and security best practices