chmod Calculator

The special bits hijack the execute position of their triad, which is why they are easy to misread. A lowercase s in the owner's execute slot means setuid and execute are both set. An uppercase S means setuid is set but execute is not — nearly always a mistake. The same rule applies to s/S in the group slot for setgid, and t/T in the others slot for the sticky bit. drwxrwxrwt on /tmp is mode 1777: world-writable, but sticky, so users cannot delete each other's files.

What execute means on a directory

This trips up nearly everyone. On a directory, the three bits do not mean what they mean on a file:

• Read (`r`) lets you list the names inside. Without it, ls fails — but you can still open a file inside if you know its exact name and have execute.
• Write (`w`) lets you create, delete, and rename entries. Note that deleting a file depends on the *directory* being writable, not the file. This is why you can delete a read-only file you do not own from a directory you do own.
• Execute (`x`) — often called the *search* bit — lets you traverse into the directory and stat things inside it. Without it, nothing below the directory is reachable at all, whatever the permissions down there say.

The practical consequence: a directory almost always needs its execute bit set wherever it has read. chmod -R 644 across a tree is the classic self-inflicted outage — it strips x from every directory and the whole path becomes unreachable, producing 403s from the web server for files that are perfectly readable. Use find to set files and directories separately.

# Directories to 755, files to 644 — never a blanket chmod -R
find /var/www/html -type d -exec chmod 755 {} +
find /var/www/html -type f -exec chmod 644 {} +

# Symbolic form does the same thing in one pass:
# capital X sets execute ONLY on directories and files that already have it
chmod -R u=rwX,go=rX /var/www/html

# See what you have before you change it
stat -c '%a %A %U:%G %n' /var/www/html/index.php   # Linux
stat -f '%Lp %Sp %Su:%Sg %N' /var/www/html/index.php  # macOS/BSD

Why 777 is almost always the wrong fix

chmod 777 grants read, write, and execute to every account on the machine. On a shared host that includes every other customer. On a VPS it includes every service account — the mail daemon, the monitoring agent, and anything an attacker manages to run as nobody. A world-writable PHP file is a persistent backdoor waiting for anyone who can already run code as any user at all; they rewrite your file, and the web server executes it as itself.

It is also almost never the actual fix. "Permission denied" from a web application means the *web server user* cannot read or write the path. The correct remedy is to make that user the owner, or put it in the owning group, and keep the mode restrictive. chown -R www-data:www-data uploads && chmod 755 uploads solves the upload-directory problem properly; chmod 777 uploads solves it by removing the lock from the door.

Modes worth memorising

SSH is the strictest consumer of permissions you are likely to meet. sshd refuses to use a private key that any group or other can read, and refuses ~/.ssh/authorized_keys if the home directory itself is group-writable — silently falling back to password auth, which then fails. 700 on ~/.ssh, 600 on private keys, 644 on authorized_keys and public keys.

umask: why new files are never 777

Processes create files requesting mode 666 and directories requesting 777; the umask then subtracts bits. The common default 022 clears write for group and other, producing 644 files and 755 directories. A umask of 002 produces 664 and 775, which is what you want on a machine where a group collaborates. umask masks bits off — it can never add a bit that the creating program did not ask for, which is why new files are never executable by default.

umask          # -> 0022
umask -S       # -> u=rwx,g=rx,o=rx

# 666 & ~022 = 644 for files; 777 & ~022 = 755 for directories
install -m 600 /dev/null secret.env   # bypass umask explicitly

Symbolic chmod, when it is the better tool

Octal sets every bit at once, which is exactly what you want for a known target state and exactly what you do not want for a targeted change. Symbolic mode edits bits relative to what is there: chmod +x deploy.sh adds execute for everyone the umask allows, chmod u+x,go-w file adds owner-execute and removes group/other write in one call, and chmod g=u file copies the owner triad onto the group. The capital X mentioned above only adds execute where it makes sense, which makes chmod -R u=rwX,go=rX safe on a mixed tree where a blanket octal recursion would not be.

One thing chmod cannot do is change *who* the owner and group are — that is chown and chgrp. If a mode looks right and access still fails, check ownership next, then check every parent directory's execute bit, then check whether SELinux or AppArmor is denying it (ausearch -m avc on RHEL-family systems will tell you in seconds what ls -l never will).