chmod Calculator Guide: Reading Unix File Permissions in Octal and Symbolic Notation
A plain-English guide to Unix file permissions and chmod: how octal and symbolic notation work, what 644 and 755 mean, and why 777 is a security risk.
chmod Calculator Guide: Reading Unix File Permissions in Octal and Symbolic Notation
Every file on a Unix or Linux box carries a small set of rules about who is allowed to do what with it. Those rules are what chmod edits, and they are the reason an SSH key gets rejected, a shell script refuses to run, or a web server hands back a 403 instead of your page. The notation looks cryptic the first few times you see it, but it is built on arithmetic you can do in your head once the pattern clicks. This guide walks through that pattern, then shows the two numbers you will type most often and the one you should almost never type.
Three identity classes, three permissions each
A Unix permission set answers two questions at once: who, and what they can do. The "who" is split into three classes. The owner is the user who owns the file. The group is a named set of users the file belongs to. Others is everyone else with an account on the machine. Each of those three classes gets its own independent set of permissions, which is why you can let yourself write a file while the rest of the team only reads it.
The "what" is three permissions: read, write, and execute. Read means you can see the contents; write means you can change them; execute means you can run the file as a program (or, for a directory, enter it and look up names inside). Three classes times three permissions gives nine bits total, and chmod is the command that flips them.
The octal trick: read=4, write=2, execute=1
The dense way to write permissions is three octal digits, one per class, in the order owner, group, others. Each digit is a sum of the three permission values:
- read = 4
- write = 2
- execute = 1
Add together whichever permissions you want and you get the digit. Read plus write plus execute is 4 + 2 + 1 = 7. Read plus execute (no write) is 4 + 0 + 1 = 5. Read only is 4. Nothing at all is 0. Because the three values are powers of two, every combination produces a unique sum from 0 to 7, so the digit and the permissions are interchangeable with no ambiguity.
So 755 decodes class by class: owner = 7 = read + write + execute, group = 5 = read + execute, others = 5 = read + execute. The symbolic form spells the same thing out as rwx r-x r-x — a letter where the bit is set, a dash where it is not. That is exactly what ls -l prints in the leading column. Once you can sum 4 + 2 + 1 in your head, you can read any of these forms without looking anything up.
A worked example: 644 for a file, 755 for a script
Take the most common file permission, 644. Digit by digit: owner = 6 = 4 + 2 = read + write; group = 4 = read; others = 4 = read. In symbolic form that is rw-r--r--. In English: the owner can edit the file, and everyone else can only read it. That is the right default for source code, configuration files, documents, and basically anything that is data rather than a program. Nobody can run it (no execute bit anywhere), and nobody but the owner can change it.
Now take a shell script you actually want to run, and give it 755. Owner = 7 = read + write + execute, group = 5 = read + execute, others = 5 = read + execute, which is rwxr-xr-x. The difference from 644 is the execute bit, now set for all three classes. The owner can edit and run it; everyone else can run it but not modify it. The same 755 is what you want on directories, because a directory's execute bit is what lets you cd into it and look up the names inside — a directory at 644 cannot even be entered by its owner. Two numbers, 644 and 755, cover the vast majority of day-to-day permission work.
I keep a third number in muscle memory: 600 (rw-------), owner read and write, nothing for anyone else. The first time I scp'd a private key to a fresh server and ran ssh, OpenSSH flatly refused it — "Permissions 0644 for id_ed25519 are too open." It will not load a key that the group or the world can read, and it silently ignores anything looser than 600. Now whenever I move a key I run chmod 600 on it and chmod 700 on the ~/.ssh directory before I even try to connect, and the whole class of "why won't it authenticate" headaches disappeared. If you want to see any of these decode live, paste the octal or symbolic form into the Linux permission (chmod) calculator and it shows all three notations at once.
Why 777 is a loaded gun
Sooner or later you will hit "permission denied," and the internet is full of advice that says chmod 777 will make it go away. It will — and that is exactly the problem. 777 is rwxrwxrwx: every local user, every service account, every process on the machine can read, write, and execute the file. World-writable means any other user on the box can overwrite the file with their own contents, so anything that later runs or includes it is now running code they chose. On a shared host or a container that runs untrusted workloads, that is a direct path to compromise.
It gets worse when special bits are involved. A leading digit in front of the three (like 4755) sets setuid, which makes a program run as its owner rather than as whoever launched it — that is how /usr/bin/passwd can edit a root-owned file on your behalf. Combine setuid-root with world-writable and you get 4777, a textbook local privilege escalation: anyone overwrites the binary with their own program and it runs as root the next time it is called. The honest fix for a permission error is almost never a bigger number. It is usually a smaller one plus the correct owner — for a web file, that often means chown www-data:www-data file followed by chmod 644 file, not opening it up to the entire machine.
Symbolic chmod for surgical changes
Octal sets all nine bits at once, which is great when you know the final state and clumsy when you only want to nudge one thing. For that, chmod also speaks a symbolic syntax: a who (u owner, g group, o others, a all), an operator (+ add, - remove, = set exactly), and a permission (r, w, x). So chmod +x deploy.sh adds the execute bit for everyone without touching read or write, chmod g-w report.txt removes group write and leaves the rest alone, and chmod u=rw,go=r notes.md sets the file to 644 spelled out. Symbolic mode is the safer choice when you are changing one permission on a file whose other bits you do not want to disturb — you say what to change instead of restating everything. If your work is more cheatsheet-shaped, the nginx cheatsheet lives in the same neighborhood of "commands I look up just often enough to forget."
Quick reference you can keep
- Read 4, write 2, execute 1 — add them per class to get each octal digit.
- 644 (
rw-r--r--) — normal files: owner edits, everyone reads. - 755 (
rwxr-xr-x) — scripts, binaries, and every directory. - 600 (
rw-------) — SSH private keys and secrets; OpenSSH demands it. - 700 (
rwx------) — private directories like~/.ssh. - 777 — almost always wrong; reach for a smaller number plus the right owner.
Permissions stop being intimidating the moment you internalize the 4-2-1 sum and the owner/group/others order. Decode a few real values by hand, lean on 644 and 755 for the common cases, treat 777 as a warning sign rather than a fix, and most "it won't run" or "it won't authenticate" problems turn into a single, obvious chmod.
Made by Toolora · Updated 2026-06-13