Linux File Permissions: chmod and chown Explained in Practice

You deployed your application to a VPS, ran the command, and the terminal returned Permission denied. Or nginx returned 403 even though the file is right there, visible in ls. This error is the gateway every developer hits when they leave the desktop environment and meet a multi-user system for the first time. The good news: the Linux permission model is simple and predictable once you understand three things — who owns the file, who belongs to the group, and what each bit means.

This guide is for anyone who has seen chmod 777 in some tutorial without understanding what it actually does, or who needs to fix file access without throwing the whole server open. We will cover how to read ls -l output, what rwx means for files and directories, and how to use chmod (change permission) and chown (change owner) in real web server scenarios.

Estimated time: 20 to 30 minutes to read, run the commands, and lock in the mental model. You walk away able to diagnose any permission error on your own.

Prerequisites

How Linux represents permissions

Every file on Linux has three associated entities: the owner (user/owner), the group, and the rest of the world (others). For each of those three entities, there are three permission bits: r (read), w (write), and x (execute). Nine bits in total — three for owner, three for group, three for world.

Run ls -l in any directory to see this rendered:

ls -l /etc/hosts

The output looks like:

-rw-r--r-- 1 root root 220 May 14 10:22 /etc/hosts

Decoding from left to right:

• - in the first character indicates a regular file. A directory would show d, a symbolic link l.
• rw- (characters 2-4): owner permissions. Reads and writes, does not execute.
• r-- (characters 5-7): group permissions. Read only.
• r-- (characters 8-10): world permissions. Read only.
• 1: number of hard links.
• root root: owner and group, respectively.
• 220: size in bytes.
• May 14 10:22: last modification.
• /etc/hosts: file name.

Octal notation: the shortcut everyone uses

Each set of three bits (rwx) can be represented by a digit from 0 to 7. Each bit has a weight:

• r = 4
• w = 2
• x = 1

Sum the weights of the enabled bits to get the digit. Practical examples:

Since each file has three sets (owner, group, world), the complete permission becomes a three-digit number. 644 is rw-r--r--. 755 is rwxr-xr-x. 600 is rw-------. This is the notation you will use 95% of the time with chmod.

The magic meaning of x on directories

On a file, x means execute as a program. On a directory, x means enter the directory (use cd) and access files by name. Without x on a directory, you cannot list its contents even with r, and you cannot open files inside even if you know the name.

That is why the classic default is 755 for directories (everyone can enter and list) and 644 for files (everyone reads, only the owner writes, no one executes). Inverting this breaks access in strange ways — files that exist but “do not exist” for another user.

chmod: changing permissions in practice

chmod accepts two notations: octal (the one shown above) and symbolic (u+x, g-w, o=r). Octal is more common in production because it is deterministic — you define the final state, not the transition.

mkdir ~/perms-test
cd ~/perms-test
echo "test content" > file.txt
ls -l file.txt

chmod 600 file.txt
ls -l file.txt

chmod 644 file.txt
ls -l file.txt

chmod u+x file.txt
ls -l file.txt

Recursive chmod: -R with care

The -R flag applies the change to everything inside a directory. Useful in specific situations, dangerous in others:

chmod -R 755 ~/perms-test

The problem: this adds x on every file, including ones that should not be executable. On /var/www/site, you want 644 for .html, .css, .php files and 755 only for directories. The correct form separates by type:

find /var/www/site -type f -exec chmod 644 {} \;
find /var/www/site -type d -exec chmod 755 {} \;

Or, more efficient on large directories:

find /var/www/site -type f -print0 | xargs -0 chmod 644
find /var/www/site -type d -print0 | xargs -0 chmod 755

chown: changing owner and group

chown changes the file’s owner. Basic syntax:

chown new_owner file
chown new_owner:new_group file
chown :new_group file

Only root (or a user with sudo) can change ownership to another user. A regular user cannot give their file to someone else — this prevents attacks where someone dumps files into another user’s quota.

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

ls -l /var/www/site | head

Verification: confirm it is correct

After messing with permissions, validate three things: the current state of the bits, ownership, and that the application can actually read.

ls -ld /var/www/site
ls -l /var/www/site | head
sudo -u www-data cat /var/www/site/index.html

ls -ld shows the permission of the directory itself (without -d, it lists contents). sudo -u www-data runs the command as if it were the web service user — if this works without error, your application will too. This test is more reliable than just looking at ls -l because it covers SELinux/AppArmor if they are active.

To verify the selective recursive chmod worked, count files by permission:

find /var/www/site -type f -perm 644 | wc -l
find /var/www/site -type f ! -perm 644

The second line should return nothing. If it does, those are files with a permission other than 644 — investigate case by case before applying a mass fix.

Troubleshooting

”Permission denied” even after chmod 755

Check ownership with ls -l. If the file belongs to root:root and the process runs as www-data, 755 only helps the other bit (last digit). But on some systems with SELinux active, extra security contexts block access regardless of Unix permission. Check with ls -Z and use restorecon or chcon if needed.

”Operation not permitted” when running chown

You are not running as root. Even if you own the file, transferring it to another user requires sudo. Add sudo before the command or run as root.

Parent directory without execute permission blocks access

Classic scenario: /home/user/public_html/site/index.html has 644, but nginx returns 403. The problem might be in /home/user — if that folder does not have x for group/world, nginx (running as www-data) cannot traverse the path to the file. Solution: ensure x on every directory in the path, or use a /var/www structure where permissions are designed for web access from the start.

Next steps

Basic permissions cover most scenarios, but there are advanced layers worth exploring as your setup gets more complex:

• ACLs (Access Control Lists): allow per-user permissions beyond the owner/group/world trio. Commands getfacl and setfacl. Useful when two services need different access to the same file.
• Special bits: setuid (4000), setgid (2000), and sticky bit (1000). The sticky bit on /tmp is the classic example — it prevents user A from deleting user B’s files.
• umask: the value that defines the default permission for new files. Configure it in /etc/profile or the user’s shell rc so files are created with the right permission from the start.
• Capabilities (setcap): a modern alternative to setuid for granting specific privileges (e.g. binding to ports < 1024) without giving full root.

If you are taking an application to production and need real isolation, root access, and dedicated SSH to practice these commands without affecting production, a Hostini VPS delivers that with Ubuntu 24.04 LTS pre-installed and snapshots so you can revert any experiment.