What Does chmod 755 Mean? (And How to Read Any Permission)

You found the fix on Stack Overflow — chmod 755 deploy.sh — and it worked. But 755 is three digits with no obvious meaning, so the next time a script won’t run or a web server returns 403, you’re back to copying numbers and hoping. The good news: those digits aren’t a magic incantation. They’re a compact code you can read on sight, and once you can, 755, 644, and 700 stop being things you paste and start being decisions you make.

Three classes, three permissions

Every file and directory on a Unix system carries permissions for three classes of user:

• owner (u) — usually whoever created it
• group (g) — a set of users who share access
• other (o) — everyone else

For each class, three permissions are independently on or off:

• read (r) — view the contents
• write (w) — change the contents
• execute (x) — run it as a program (for a directory this means something different — hold that thought)

Run ls -l and you see all of it at once:

-rwxr-xr-x  1 alice  devs  482 Jul 29 09:14 deploy.sh

That -rwxr-xr-x is the entire permission set. Read it in three groups of three, after the first character:

• the leading - is the file type, not a permission (- = regular file, d = directory, l = symlink) — a common misread
• rwx — the owner may read, write, and execute
• r-x — the group may read and execute, but not write
• r-x — others get the same: read and execute, no write

A dash means that permission is off. So -rwxr-xr-x is exactly what chmod 755 produces on a regular file — the same permissions on a directory would read drwxr-xr-x, with a d in that first slot instead of the -. Now let’s see why.

Each digit is a sum: 4, 2, 1

The three digits in 755 map to the three classes, in order — owner, group, other. Each digit encodes that class’s three permissions by adding up fixed values:

Add the values for the permissions you want on, and you get a single digit from 0 to 7:

So 755 reads left to right as:

• 7 → owner: 4 + 2 + 1 = rwx
• 5 → group: 4 + 1 = r-x
• 5 → other: 4 + 1 = r-x

The owner can do everything; group and other can read and execute but not modify. That’s chmod 755. And 644:

• 6 → owner: 4 + 2 = rw-
• 4 → group: r--
• 4 → other: r--

The owner can read and write; everyone else can only read. Nothing has execute — exactly right for a normal data file, and exactly wrong for a script you need to run.

You never have to memorize the combinations. Toggle the read/write/execute boxes for each class in the chmod calculator and the octal and the rwxr-xr-x string update together, until the mapping is muscle memory.

The modes you’ll actually see

A handful of numbers cover most real cases. Here’s what they mean and where they turn up — and if the question is which one to give a particular file, or how to apply the split across a whole project tree, chmod 644 vs 755 takes that decision apart:

Two patterns explain most of the table. Data files get 644 (or 600 when private): read/write for the owner, read-only or nothing for everyone else, no execute. Things you traverse or run — directories and programs — get 755 (or 750/700 to narrow the audience): the same idea as 644 plus the execute bit, because without execute you can’t do the one thing they exist for. Which raises the question most tutorials skip.

Execute means something different for a directory

For a file, x is straightforward: permission to run it as a program. For a directory, x has nothing to do with running anything — and this is where 755 on a folder finally makes sense.

On a directory:

• r lets you list the names inside it (ls)
• x lets you search the directory — enter it with cd, traverse it, and reach a file by a name you already know
• w — but only together with x — lets you create, rename, and delete entries

The surprising part is how independent r and x are. A directory with r but no x lets you see the file names but not read the files themselves, or even stat them. A directory with x but no r lets you open a file inside if you already know its exact name, but ls fails. And changing what’s in a directory — creating or deleting a file — needs w and x on that directory, not on the files. In practice you want r and x together, which is why directories others need to traverse are usually 755 rather than 644: drop the execute bits and nobody can get into the folder at all.

There’s a knock-on effect that catches people the first time: to reach /var/www/site/index.html, you need x on every directory in the path — /, /var, /var/www, and /var/www/site. One ancestor missing its execute bit blocks access to everything beneath it, no matter how open the file itself is. You can inspect the whole chain at once with ls -ld / /var /var/www /var/www/site and scan for any line missing its x. It’s a frequent cause of a “permission denied” you can’t explain by staring at the file alone — a mode that looks correct but still gets rejected is worth a troubleshooting pass of its own, which is what permission denied even after chmod walks through.

Symbolic notation: the other way to say it

Octal sets all nine bits at once. Symbolic notation flips specific ones and reads more like a sentence:

chmod +x deploy.sh        # add execute for all classes (but see the umask note)
chmod u+x deploy.sh       # add execute for the owner only, nothing else touched
chmod go-w file           # remove write from group and other
chmod u=rw,go=r file      # set exactly: owner rw, group and other r  (= 644)

The pieces are a who (u owner, g group, o other, a all), an operator (+ add, - remove, = set exactly), and the permissions (r, w, x). One subtlety: when you omit the who, as in a bare chmod +x, it aims at all three classes but is filtered by your umask, so it won’t necessarily turn on every execute bit. Name the class — u+x, a+x — when you want to be sure. Reach for octal when you want to state a file’s whole mode from scratch; reach for symbolic when you want to flip one bit without disturbing the rest. The calculator goes both directions — type a symbolic string and read off the octal, or build the octal and read off the symbolic. It converts the permission bits and can’t see your machine’s umask, so give a bare +x an explicit who — u+x, a+x — when you want the tool to match the command you’ll actually run.

Reading permissions across systems

Setting a mode works the same way on Linux, macOS, and the BSDs. Just don’t read the two commands above as interchangeable: chmod 755 sets the complete basic mode at once, while chmod u+x changes only the owner’s execute bit and leaves the rest as it was. Reading the current mode back is where the systems differ:

• ls -l prints the -rwxr-xr-x form everywhere — again, the first character is the file type, not a permission.
• To get the octal directly: on GNU/Linux, stat -c '%a' file; on macOS/BSD, stat -f '%Lp' file. (stat -c '%A' on Linux prints the symbolic form.)
• Windows uses a different model entirely: NTFS relies on ACLs, not Unix mode bits, so native Windows tools don’t act on a 755. Under WSL, files on the Linux filesystem behave normally, but on a mounted Windows drive (/mnt/c) the outcome depends on the DrvFS metadata options and the underlying Windows ACLs — chmod there isn’t necessarily equivalent to chmod on a native Linux filesystem, and a mode that displays as 777 still can’t override the ACL.

What 755 doesn’t tell you

Three things sit just outside those three digits, and each is a common source of confusion:

1. A fourth, leading digit. 755 is really 0755. That leading 0 is a slot for the special bits, and they decode just like the others:

   Digit	Bit	Example
   4	setuid — run the program as the file’s owner	4755 on an executable
   2	setgid — run as the file’s group; on a directory, new entries inherit its group	2775 on a shared directory
   1	sticky — in a shared directory, an entry can be renamed or deleted only by its owner, the directory’s owner, or root	1777 on /tmp

   Decoding them is this easy. What they actually do at runtime — and the ways they surprise you — is a walkthrough of its own.

2. Ownership. Permissions decide what the owner, group, and other may do — but chmod never changes who the owner and group are. That’s chown’s job, and mixing up the two is behind a lot of “I set it to 777 and it still won’t work” frustration.

3. Other gatekeepers entirely. The mode is only the first check. An ACL, a SELinux or AppArmor policy, a read-only or noexec mount, or a missing x on a parent directory can all deny access to a file whose own mode looks wide open. It’s why chmod 777 sometimes changes nothing — and why “any permission” here means reading the mode, not every layer that guards a file. Untangling those layers is its own troubleshooting pass.

A reading checklist

When a mode lands in front of you:

1. Split it into three digits — owner, group, other, in that order.
2. Decompose each digit with 4 (r) + 2 (w) + 1 (x). 7 is rwx, 6 is rw-, 5 is r-x, 4 is r--.
3. Remember what execute means for the target. On a file it’s “run me”; on a directory it’s “enter me and reach what’s inside.”
4. Check for a fourth digit. A leading 1, 2, or 4 is a special bit — sticky, setgid, or setuid. Decode it the same way; its runtime behavior is a separate story.
5. Separate permission from ownership. The mode says what owner, group, and other may each do; chown changes a file’s owner and group, and which class applies to a given user depends on their identity and group membership.

Do that and 644, 755, and 700 read on sight. And when you’d rather confirm than decode — or see a mode and its rwxr-xr-x string side by side — paste it into the chmod calculator: octal in, symbolic out, both directions, with the file-versus-directory meaning spelled out.