TechEarl

Linux File Permissions Explained (chmod and Octal)

Read and set rwx permissions, the octal numbers behind 644 and 755, the difference between files and directories, and symbolic vs numeric chmod.

Ishan Karunaratne⏱️ 5 min readUpdated
Share thisCopied
Read and set Linux rwx permissions, the octal numbers behind 644 and 755, files vs directories, and symbolic vs numeric chmod.

Every file has three permissions (read, write, execute) for three classes of user (owner, group, other). That nine-bit grid is the whole model. Read it straight off ls -l:

Terminal showing ls -l output: a file at -rw-r--r-- (644), a script at -rwxr-xr-x (755), and a directory at drwxrwxr-x, with owner, group, and other permission columns.
The first column is the permission grid: type, then rwx for owner, group, and other.

Reading the grid

Take -rw-r--r--:

  • Character 1 is the type: - file, d directory, l symlink.
  • Characters 2-4 are the owner's permissions: rw- = read, write, no execute.
  • Characters 5-7 are the group's: r-- = read only.
  • Characters 8-10 are other (everyone else): r-- = read only.

So -rw-r--r-- means the owner can read and write; everyone else can only read. That is the default for a normal file, and the octal for it is 644.

The octal shorthand

Each rwx triplet is a number: read = 4, write = 2, execute = 1. Add them up per class:

SymbolicOctalMeaning
rwx7read + write + execute
rw-6read + write
r-x5read + execute
r--4read only
---0nothing

So three digits describe the whole grid:

  • 644 (rw-r--r--), normal file: owner edits, others read.
  • 755 (rwxr-xr-x), script or directory: owner full, others read/run.
  • 600 (rw-------), private file, like an SSH key: owner only.
  • 700 (rwx------), private directory: only the owner can enter.
bash
chmod 644 notes.txt
chmod 755 deploy.sh
chmod 600 ~/.ssh/id_ed25519

Worked the other way, chmod 750 deploy.sh reads as owner 7 (rwx = 4+2+1), group 5 (r-x = 4+1), other 0 (---): the owner can read, write, and run it, the group can read and run it, everyone else gets nothing.

To read a file's mode as the octal number directly, instead of decoding the rwx string by eye:

bash
stat -c '%a %n' deploy.sh        # Linux, prints e.g. 750 deploy.sh
stat -f '%A %N' deploy.sh        # macOS / BSD equivalent

Rather than do the arithmetic in your head, tick what each class should be allowed to do and read off the octal (or type an octal to decode it):

chmod permissions calculator
Read4Write2Execute1ownergroupother
Special
Symbolicrw-r--r--
chmod 644 filename

Owner can read, write; group can read; others can read.

Quick presets
ModeSymbolicUsed for

Tap any mode to load it, set the path and scope, then copy the command. Your selection is saved on this device.

A standalone version with the common modes laid out lives on the chmod calculator page.

Symbolic chmod, when you want to change one bit

Numeric sets all nine bits at once. Symbolic changes just what you name, which is safer when you do not want to disturb the rest:

bash
chmod u+x deploy.sh        # add execute for the owner (u)
chmod go-w shared.txt      # remove write for group and other
chmod a+r public.txt       # add read for all (a = ugo)

u owner, g group, o other, a all; + add, - remove, = set exactly.

Execute means different things for files and directories

This is the part that confuses everyone. On a file, the execute bit (x) means "can be run as a program". On a directory, x means "can enter / traverse it" (cd into it, access files inside by name). A directory you can read but not execute lets you list names but not actually reach the files. That is why directories are 755 (with x) and not 644. The capital-X form on chmod -R exists exactly for this; see chmod recursively.

FAQ

See also

Sources

Authoritative references this article was fact-checked against.

TagsLinuxchmodFile PermissionsOctalSystem Administration

Found this useful? Pass it on.

Copied

Ishan Karunaratne

Software Systems Architect · Senior Software Engineer · Engineering Leadership

Software systems architect and senior software engineer with more than two decades designing, building, and running production software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Now a CTO, though what I write here is drawn from the full arc of that work, across architecture, engineering, and operations, not any single job.

Keep reading

Related posts