Linux File Permissions Explained: Reading rwx and Octal Like a Pro
By the UtilityForge Editorial Team · Published October 22, 2026 · 6 min read
If you've ever run ls -l and wondered what -rwxr-xr-- was trying to tell you, this is for you. Linux permissions look cryptic at first, but there are only three ideas to learn, and they stack neatly.
Three people, three actions
Every file has an owner, a group, and then everybody else ("others"). For each of those three, the system records whether they can read (r), write (w) or execute (x).
The first character in the ls -l output shows the type (- for a file, d for a directory). The next nine characters are three groups of three: owner, group, others. So -rwxr-xr-- means a file where the owner can do everything, the group can read and execute, and others can only read.
Where the numbers come from
Octal notation is just a shortcut. Give read the value 4, write 2 and execute 1, then add them up for each group:
7= 4+2+1 = read, write, execute6= 4+2 = read, write5= 4+1 = read, execute4= read only0= nothing
So 754 is owner 7 (rwx), group 5 (r-x), others 4 (r--). Same as the string above. Once you've done it a few times you stop converting and just see the pattern.
Files and folders behave differently
This is where people get tripped up. On a regular file, execute means "can be run as a program". On a directory, things shift:
- Read lets you list the names inside.
- Write lets you create, rename or delete entries inside.
- Execute lets you enter the directory and access things within it.
That's why directories almost always need the execute bit. A folder set to 644 looks fine until you try to cd into it and get "permission denied".
The values you'll use most
- 644 – normal files. Owner reads and writes, everyone else reads. Typical for web pages and config that isn't secret.
- 755 – scripts, programs and directories. Everyone can read and run; only the owner can modify.
- 600 – private files such as SSH keys or
.envfiles. Only the owner can touch them. - 700 – private directories, for example
~/.ssh. - 400 – read-only for the owner, good for keys you never want to edit by accident.
Why 777 is almost never the answer
When something won't work, it's tempting to run chmod 777 and move on. It does fix the error, because it removes every restriction. But it also lets any user or compromised process on the machine rewrite that file. On a shared host or a web server, that's a real security hole, and attackers look for world-writable files on purpose. If a permissions error keeps happening, the better fix is usually to correct the owner with chown, or to put the right user in the right group.
SSH is picky, on purpose
If you see "UNPROTECTED PRIVATE KEY FILE" or "bad permissions" when connecting over SSH, it's because the key can be read by other users. The client refuses to use it. The fix is short: chmod 600 ~/.ssh/id_rsa (or whichever key you're using), and chmod 700 ~/.ssh for the folder.
Symbolic form for small changes
You don't always have to type the full number. chmod u+x script.sh adds execute for the owner and leaves everything else alone. chmod go-w file removes write from the group and others. The letters are u (user/owner), g (group), o (others) and a (all); the operators are +, - and =. For big, deliberate changes the octal form is clearer; for tweaks, symbolic is safer.
Recursive changes need care
chmod -R 755 folder applies to everything inside, including regular files that probably shouldn't be executable. A common pattern is to treat files and directories separately with find: set directories to 755 and files to 644. And before you run any recursive command as root, double-check the path. A stray space or typo can be painful.
If you'd rather not do the arithmetic every time, the chmod permission calculator lets you tick boxes and shows the octal value, the symbolic string and the ready-to-paste command together.