chmod in Plain English — Why Everyone Writes 755 Without Knowing What It Means

At some point early in your career, someone told you to run chmod 755 on a directory or chmod 644 on a config file. It worked. You moved on. Now, years later, you still type those exact numbers from muscle memory — and if anyone asks you to explain what 755 actually means, you wave vaguely at a screen and say “it’s the standard permissions thing.”

This is fine, until it isn’t. The moment you need to debug a permission denied error, decide what to put on a new script, or explain to a junior dev why chmod 777 is not the fix for everything — suddenly the muscle memory isn’t enough.

Here’s what the numbers actually mean.

The Bit Structure

Unix file permissions are three sets of three bits. That’s it. Each set controls what one category of user can do — owner, group, others — and each bit within a set maps to read, write, or execute.

The values are: read = 4, write = 2, execute = 1. You add them together for each set. So 7 means read + write + execute (4+2+1). 5 means read + execute (4+1). 4 means read only.

Break down 755: owner gets 7 (rwx), group gets 5 (r-x), others get 5 (r-x). In binary: 111 101 101. In symbolic notation: rwxr-xr-x. The default you’ve been typing forever is just “owner can do everything, everyone else can read and execute but not write.”

Reading ls -la Output

Run ls -la in any directory and you get something like this:

drwxr-xr-x  2 deploy www-data 4096 May 29 10:00 public_html
-rw-r--r--  1 deploy www-data 2341 May 29 09:45 config.php
-rwx------  1 deploy deploy    891 May 28 14:20 deploy.sh
-rw-------  1 deploy deploy    411 May 10 08:30 .env

The first character is the file type: d for directory, - for regular file, l for symlink. Then come three groups of three characters — owner, group, others. A dash means the permission is absent.

The number after the permissions is the hard link count. Then owner name, group name, file size in bytes, modification timestamp, and finally the filename.

So drwxr-xr-x 2 deploy www-data means: directory, owner (deploy) can read/write/execute, group (www-data) can read and traverse but not write, everyone else can read and traverse but not write. Two hard links. That’s your standard web directory.

Common Permission Values and Why They Exist

Here’s the breakdown of the values you’ll actually use, what they mean, and when to reach for each one:

Value	Symbolic	Binary	What it means	When to use it
755	rwxr-xr-x	111 101 101	Owner: full. Group/Others: read + execute	Directories, public executables, web-served scripts
644	rw-r–r–	110 100 100	Owner: read + write. Group/Others: read only	Config files, static assets, HTML, PHP source files
600	rw——-	110 000 000	Owner: read + write. Everyone else: nothing	SSH private keys (~/.ssh/id_rsa), .env files
700	rwx——	111 000 000	Owner: full. Everyone else: nothing	Scripts containing secrets, private executables
777	rwxrwxrwx	111 111 111	Everyone: full access	/tmp, container scratch dirs — almost nowhere else

The reason directories need execute permission is that “execute” on a directory means “traverse” — the ability to enter the directory and access its contents. If a directory is r--r--r--, you can list the names of files inside but you can’t actually access them. You need the x bit to cd into it or open files. That’s why 755 and not 744 for directories.

If you want to work through these values interactively, the Chmod Calculator on IO Tools lets you toggle individual bits and see the octal and symbolic values update in real time — useful when you need to construct an unfamiliar permission value.

Symbolic Notation: When to Use It Instead

Octal notation sets all permissions at once. Symbolic notation makes incremental changes. Both are valid — the choice depends on what you’re doing.

chmod u+x script.sh adds execute permission for the owner without touching anything else. If the file is currently 644, this makes it 744. If you used octal and wrote chmod 744 script.sh, you’d get the same result — but you’d need to know the current state first.

The symbolic operators are straightforward: + adds a permission, - removes it, = sets it exactly. The targets are u (user/owner), g (group), o (others), a (all three).

chmod u+x deploy.sh          # add execute for owner
chmod g-w config.php         # remove write from group
chmod o=r public/index.html  # set others to read-only exactly
chmod a+r shared.txt         # add read for everyone

Use symbolic when you want to change one permission without resetting everything else. Use octal when you’re setting permissions from scratch or want absolute control over the final state.

Why New Files Aren’t 666 by Default

Create a new file with a text editor or touch and you’ll get 644. Create a directory and you’ll get 755. Where do those defaults come from?

Files start at a theoretical maximum of 666 (no execute by default — that has to be explicitly set). Directories start at 777. The umask subtracts from those maximums.

The default umask on most Linux systems is 022. Applied to a file: 666 – 022 = 644. Applied to a directory: 777 – 022 = 755. That’s why 644 and 755 feel like the defaults — they are, mechanically.

Run umask with no arguments to see your current value. Change it in your shell profile if you need tighter defaults — umask 027 gives you 640 files and 750 directories, which removes all permissions for “others” and only allows group to read.

chmod 777: Not Evil, Just Lazy

Here’s the honest take on chmod 777: it’s not a security catastrophe in every context. It’s almost never the right answer in production, and people use it because it makes the permission error go away without requiring any thought.

On a shared server, chmod 777 on a writable directory means any process running under any user — including a compromised web application — can write to that directory. That’s a real attack surface. It’s also exactly the kind of thing that ends up staying in production forever because “we’ll fix it later.”

Appropriate uses for 777:

• /tmp in a throwaway container — nothing persists, nothing matters, move on
• Debugging a permission issue in development — use it to confirm permissions are the problem, then set the correct value
• Shared scratch directories on a trusted, single-user machine — if you’re the only user, the “others” permission is academic

The diagnostic workflow is: hit a permission denied error, temporarily apply 777 to confirm it’s a permissions issue and not something else, then figure out what the correct permission actually is and set that instead. chmod 777 as a diagnostic tool is fine. chmod 777 in a deploy script that nobody revisits is how breaches happen.

The Values Worth Knowing

You don’t need to memorize every possible combination. These four cover about 95% of real-world cases:

• 755 — directories and executables that should be publicly accessible
• 644 — files that should be readable by everyone but writable only by the owner
• 600 — sensitive files: SSH keys, credentials, .env files. SSH will refuse to use a private key that isn’t 600 or stricter.
• 700 — scripts that run with secrets inside them and shouldn’t be executed by anyone else

When you run into something outside this range, work from the bit structure: decide what owner, group, and others each need to do, add up the bits, write the number. The Chmod Calculator is useful here if you’d rather not do the mental arithmetic under pressure.

The permission model is one of those things in Unix that looks arbitrary until you understand it’s just binary addition. Once that clicks, you stop cargo-culting other people’s chmod commands and start setting permissions intentionally — which is the point.

You may also like