How to Read Chmod Permissions (Octal and Symbolic, Explained)

Chmod 755 means the file’s owner can read, write, and execute it, while the group and everyone else can only read and execute it, not modify it. Each of the three digits in a chmod number covers one class of user, owner, group, others, and each digit is built from three bits: read, write, execute.

How one octal digit is built

Three permission bits exist for every user class: read (value 4), write (value 2), execute (value 1). Add up whichever bits are turned on and you get that class’s single digit, 0 through 7.

• 4 = read only
• 6 = read + write (4 + 2)
• 5 = read + execute (4 + 1)
• 7 = read + write + execute (4 + 2 + 1)
• 0 = nothing at all

A chmod command lists three of these digits back to back, always in the same order: owner, group, others. chmod 750 file breaks down as 7 for the owner (read, write, execute), 5 for the group (read, execute), 0 for others (nothing). No memorization needed, just add the bits that apply to each class.

Worked examples you’ll actually run into

Command	Octal	Symbolic	Typical use
chmod 600 file	600	rw-------	SSH private key (id_rsa), .env / secrets file
chmod 644 file	644	rw-r—r—	Regular file (HTML, config, log), owner edits, everyone reads
chmod 700 dir	700	rwx------	Private folder only the owner can enter
chmod 755 script.sh	755	rwxr-xr-x	Public script or directory, owner edits, everyone can run/enter
chmod 775 dir	775	rwxrwxr-x	Shared team directory, owner and group can write
chmod 777 file	777	rwxrwxrwx	Everyone can read, write, execute, avoid, security risk

Check the math on any row yourself: 755 means owner = 4+2+1 = 7 (rwx), group = 4+0+1 = 5 (r-x), others = 4+0+1 = 5 (r-x), which is exactly rwxr-xr-x. The pattern holds for every row in the table.

One detail that trips people up on directories specifically: a directory needs its execute bit to be entered with cd, and its read bit to be listed with ls. A directory that’s readable but not executable (like 644 on a folder) lets some tools show the names of what’s inside, but you can’t cd into it or stat the files, since traversing a directory is what the execute bit actually governs there. Read and execute do different jobs on a directory than they do on a plain file.

Two different things called “symbolic”

This is where most explainers get sloppy, because chmod has two unrelated things both commonly called “symbolic”:

The ls -l display string, like rwxr-xr-x. This is what you see when you list files, and it’s an absolute snapshot of the current permissions, ten characters: a file-type flag followed by three groups of rwx for owner, group, others. It’s a description, not a command.

Chmod’s own symbolic mode syntax, used to change permissions relative to what they already are. Instead of specifying the full three-digit number, you target a class and a bit:

• chmod u+x file.sh adds execute for the owner (user) only, leaving group and others untouched
• chmod go-w file removes write from group and others, leaving owner alone
• chmod a+r file makes the file world-readable (all classes)

The difference matters in practice: octal mode (chmod 755) always sets an absolute, complete permission state, overwriting whatever was there before. Symbolic mode (chmod u+x) makes a relative adjustment to whatever the current permissions already are, without touching the rest. Reach for symbolic mode when you want to flip one bit without recalculating the whole three-digit number by hand.

Try it with your own permissions

Chmod Calculator

Free, no sign-up, works on any device.

Open the full tool

Why new files default to 644 and new directories to 755

Nobody runs chmod on every file they create, yet new files almost always come out 644 and new directories 755. That’s umask at work, not coincidence.

New files start from a base of 666 (rw-rw-rw-, no execute bit by default, for safety, since you don’t want every new file spontaneously executable). New directories start from 777 (rwxrwxrwx). The shell’s umask value then gets subtracted from that base. The default umask on most Linux systems is 022, so:

• 666 − 022 = 644 for a brand-new file
• 777 − 022 = 755 for a brand-new directory

That’s the entire mechanism behind the two most common permission values in the table above. If your system produces something other than 644 and 755 on freshly created files, check umask in your shell, it’s almost certainly set to a non-default value.

Common mistakes and the security angle

chmod 777 is a red flag, not a fix. Setting a file or directory to 777 gives every user on the system, including an attacker who’s gained any foothold at all, permission to read, write, and replace it. An insecure file upload combined with a 777 upload directory is a textbook way a web app turns into a webshell. Security scanners used in WordPress and hosting audits routinely flag 777 as a critical finding on sight. The fix is almost always 755 for executables and directories, 644 for regular files, and tightened further to 750 or 640 when there’s a trusted group that needs write access but the wider world doesn’t.

SSH refuses an over-permissive private key. ssh-keygen creates private keys at 600 by default, and OpenSSH actively enforces that: if your id_rsa ends up group- or world-readable, SSH refuses to use it and prints something like “UNPROTECTED PRIVATE KEY FILE!” along with “Permissions 0644 for ‘id_rsa’ are too open.” This isn’t a cosmetic warning, it’s a hard block, and it’s the single most common reason someone’s SSH key “stops working” after being copied between machines or extracted from a backup, since copying often resets permissions to something more open than 600.

Scope note: setuid, setgid, and the sticky bit

The chmod calculator above covers the standard three-digit owner/group/others set, which handles the vast majority of real-world cases. What it doesn’t model is an optional fourth, leading digit for special permission bits: setuid (4000), setgid (2000), and the sticky bit (1000), combined into modes like chmod 4755 or chmod 1777.

In one sentence each: setuid runs a binary with its owner’s privileges rather than the caller’s (the classic example is /usr/bin/passwd, which needs elevated access to update the system password file), and the sticky bit on a world-writable directory like /tmp stops one user from deleting or renaming files another user owns there, even though everyone can write to the directory.

Frequently asked questions

What does chmod 755 mean? The owner gets read, write, and execute (7 = 4+2+1). The group and everyone else get read and execute only, no write (5 = 4+0+1 each). In symbolic form that’s rwxr-xr-x, the standard permission for a script or public directory: the owner can edit it, everyone else can run it or enter it.

What’s the difference between chmod 644 and 755? 644 removes the execute bit entirely (rw-r—r—), which is correct for regular files like HTML, configs, or logs that should never run as a program. 755 keeps execute for every class (rwxr-xr-x), which is what a script or a directory needs, since directories require execute to be entered at all. Use 644 for data, 755 for anything that needs to run or be traversed.

Why does chmod 600 matter for SSH keys? Because OpenSSH checks the permission bits on a private key before using it and refuses to proceed if the key is readable by the group or by others. 600 (rw-------) means only the file’s owner can read or write it, which is exactly what a private key needs: nobody else on the system should even be able to view its contents.

Is chmod 777 ever the right answer? Almost never in production. It grants full read, write, and execute to every user on the system, which is a common root cause behind file uploads getting overwritten with malicious code. If something seems to require 777 to work, the actual problem is usually a mismatched file owner or group, fixable with chown, not a reason to open permissions to everyone.

What’s the difference between rwxr-xr-x and chmod u+x? rwxr-xr-x is the ls -l display string, a snapshot of the current, complete permission state. chmod u+x is a command using chmod’s symbolic mode syntax to make a relative change, adding execute for the owner without touching anything else. One describes where permissions stand right now; the other is one way to change them.