Unix File Permissions Explained: rwx, Octal Notation, umask, and Fixing 403 Errors

Every "403 Forbidden," every "Permission denied," every SSH key rejected for being "too open" — they all trace back to Unix file permissions. The system is elegant once you understand it: 9 bits controlling who can read, write, and execute every file. But the octal notation (chmod 755) is opaque until someone explains the bit math.

This article covers the full model, with real error messages and fixes.

The 9-Bit Model

Every file has three permission triples, one each for user (owner), group, and other (everyone else):

-rwxr-xr--  1 alice devs  2048 Oct 18 10:30 script.sh
 │││││││││
 │││││││└┴┴─ other:  r--  (read only)
 │││└┴┴────── group:  r-x  (read + execute)
 └┴┴────────── user:   rwx  (read + write + execute)

Each position is a single bit:

Bit	Meaning for files	Meaning for directories
r (read)	Can read file contents	Can list directory contents
w (write)	Can modify/delete file	Can create/delete files in directory
x (execute)	Can run as program	Can cd into / access files inside

The directory distinction is crucial and commonly misunderstood: read on a directory lets you list filenames; execute lets you access files inside it. A directory with r-- but not --x is a tantalizing trap — you can see filenames but can't open any of them.

Octal Notation: The Bit Math

Each triple maps to one octal digit (3 bits = values 0–7):

rwx = 111 binary = 7
rw- = 110 binary = 6
r-x = 101 binary = 5
r-- = 100 binary = 4
-wx = 011 binary = 3
-w- = 010 binary = 2
--x = 001 binary = 1
--- = 000 binary = 0

So rwxr-xr-- becomes:

user:  rwx  →  111  →  7
group: r-x  →  101  →  5
other: r--  →  100  →  4

755. That's all chmod 755 means — it's just the compact way to write the 9 bits.

Common modes decoded:

Octal	Symbolic	Meaning	Typical use
777	rwxrwxrwx	Everyone can do everything	Never in production
755	rwxr-xr-x	Owner full, others read+execute	Executables, scripts, directories
644	rw-r--r--	Owner read+write, others read	Regular files, configs
600	rw-------	Owner only	SSH private keys, secrets
700	rwx------	Owner only, incl. execute	~/.ssh/ directory
444	r--r--r--	Read-only for everyone	Immutable reference files

Why 755 for Directories and 644 for Files?

This is the standard web server setup, and the logic is:

• Directories need x (execute) for the web server to traverse into them. Without it: 403 Forbidden.
• Files don't need x (they're not programs). Giving files execute permission is unnecessary and slightly increases attack surface.
• Owner needs w to update content; group/other only need r to serve it.

# Standard web directory setup
find /var/www -type d -exec chmod 755 {} \;
find /var/www -type f -exec chmod 644 {} \;

umask: Default Permissions

New files don't get random permissions — they're determined by umask, a bitmask that removes permissions from the maximum defaults:

• Files start at 666 (rw-rw-rw-), then umask bits are cleared
• Directories start at 777 (rwxrwxrwx), then umask bits are cleared

With the typical umask of 022:

Files:       666 − 022 = 644  (rw-r--r--)
Directories: 777 − 022 = 755  (rwxr-xr-x)

(The subtraction is actually bitwise AND with the complement, but octal subtraction gives the right answer for standard umasks.)

Check and set:

$ umask
0022

# More restrictive (group/other get nothing)
$ umask 077
$ touch secret.txt && ls -l secret.txt
-rw------- 1 user user 0 Oct 18 10:30 secret.txt  # 600, not 644

Special Bits: setuid, setgid, Sticky

Three extra bits appear in a fourth octal digit (prefix):

Bit	Octal	Symbol	Effect
setuid	4000	rws (user x→s)	Execute as file owner, not caller
setgid	2000	rws (group x→s)	Execute as file group; on dirs, new files inherit group
sticky	1000	rwt (other x→t)	Only owner can delete/rename files in dir

Real examples:

# setuid: passwd runs as root so it can modify /etc/shadow
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 ... /usr/bin/passwd

# setgid on directory: shared project dir
$ chmod 2775 /srv/project
$ ls -ld /srv/project
drwxrwsr-x 2 root devs ... /srv/project
# New files here inherit group 'devs' automatically

# sticky bit: /tmp — anyone can create files, but only owners can delete
$ ls -ld /tmp
drwxrwxrwt 15 root root ... /tmp

The s replaces x in the display: rwsr-xr-x means setuid + rwxr-xr-x. If you see a capital S (rwSr-xr-x), it means setuid is set but execute is not — usually a misconfiguration.

Real-World Debugging

"Permissions 0644 for '/home/user/.ssh/id_rsa' are too open"

SSH is strict about key permissions. A private key readable by anyone is a security risk, so SSH refuses to use it:

$ ssh -i ~/.ssh/id_rsa server
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.

Fix:

chmod 600 ~/.ssh/id_rsa       # Private key: owner read/write only
chmod 644 ~/.ssh/id_rsa.pub   # Public key: world-readable is fine
chmod 700 ~/.ssh              # Directory: owner only
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts

Web Server 403 Forbidden

Three permission-related causes, in order of likelihood:

# 1. Directory missing execute (can't traverse)
$ ls -ld /var/www/html
drw-r--r-- 2 www-data www-data ...  # Missing x!
$ chmod 755 /var/www/html

# 2. File not readable by web server user
$ ls -l /var/www/html/index.html
-rw------- 1 alice alice ...  # Only alice can read
$ chmod 644 /var/www/html/index.html

# 3. SELinux/AppArmor context (permissions look fine but still 403)
$ ls -Z /var/www/html/index.html
unconfined_u:object_r:user_home_t:s0  # Wrong context!
$ restorecon -Rv /var/www/html

"Operation not permitted" Despite Being Owner

You own the file, permissions say rw-, but you can't write? Check for the immutable attribute:

$ lsattr important.conf
----i---------e---- important.conf  # 'i' = immutable

$ sudo chattr -i important.conf  # Remove immutable flag

Or the file might be on a read-only mount.

Symbolic vs Octal chmod

Both work; symbolic is more readable for targeted changes:

# Octal: set absolute permissions
chmod 755 script.sh

# Symbolic: modify relative to current
chmod u+x script.sh       # Add execute for user
chmod go-w file.txt       # Remove write for group/other
chmod a+r file.txt        # Add read for everyone
chmod u=rw,go=r file.txt  # Set exactly rw-r--r-- (= 644)

Symbolic shines for surgical changes without affecting other bits. Octal is better for setting a known-good state.

Try It

Permission issues often surface when deploying web tools or debugging server configs. DailyToolbox's free developer tools run entirely in your browser — no server uploads, no permission headaches. From regex testing to JSON formatting, everything executes locally.

👉 Browse Developer Tools →

FAQ

What's the difference between 755 and 775?

755 = rwxr-xr-x (group can read+execute). 775 = rwxrwxr-x (group can also write). Use 775 for shared directories where group members need to create files (combined with setgid for proper group inheritance). Never use 775 for files served by a web server unless you have a specific reason.

Why is 777 dangerous?

777 = rwxrwxrwx — literally anyone on the system can read, modify, and execute the file. For a web-accessible file, this means any compromised process or user can inject malicious code. It's the #1 cause of "my WordPress got hacked" stories. There's almost never a legitimate reason for 777; if a tutorial tells you to use it, the tutorial is wrong — figure out the correct user/group ownership instead.

What does the 't' in drwxrwxrwt mean?

That's the sticky bit (octal 1000). On directories like /tmp, it means anyone can create files, but only the file's owner (or root) can delete or rename them. Without the sticky bit, anyone with write permission on the directory could delete anyone else's files.

How do I recursively fix permissions safely?

# Directories: 755, Files: 644 (standard web setup)
find /path -type d -exec chmod 755 {} \;
find /path -type f -exec chmod 644 {} \;

Never chmod -R 777 to "fix" a permission problem — you're creating a security hole. Identify which user needs which access and set ownership correctly with chown first.