How to Learn Linux File Permissions (Without Googling chmod 755 Every Time)

A deploy script fails with Permission denied. You SSH in, type ls -l, and stare at -rw-r--r-- like it's a license plate from another country. Then you open a new tab and search "chmod 755 meaning" for what is probably the ninth time this year.

I did this for an embarrassingly long time. I could fix the problem, but only by copying a number from Stack Overflow and hoping. The fix that finally worked was boring: learn the three or four ideas underneath the numbers, then make myself recall them a few times until they stopped leaking out.

Here's that version.

Read the string before you touch the number

Run ls -l on any file and the first column looks like this:

-rwxr-xr-- 1 deploy www-data 2048 Nov  9 10:12 release.sh

Ignore the first character for now (it's - for a file, d for a directory). The next nine characters are three groups of three:

• rwx for the owner (deploy)
• r-x for the group (www-data)
• r-- for everyone else

Each group answers the same three questions in the same order. Can you read it? Can you write it? Can you execute it? A dash means no.

That's the whole format. Once I stopped seeing it as nine random letters and started seeing it as "owner, group, others, each with read-write-execute," ls -l got a lot less scary.

The numbers are just addition

This is the part everyone memorizes instead of understanding. Read is 4. Write is 2. Execute is 1. Add up what you want for each group.

So rwx is 4 + 2 + 1 = 7. r-x is 4 + 1 = 5. r-- is 4.

That means chmod 754 release.sh gives you exactly the string above. And the famous 755 is "owner can do everything, group and others can read and run it." 644 is "owner can read and write, everyone else can only read," which is what most plain files should look like.

I stopped needing a chart when I realized there are only eight possible digits, and I only ever use four of them: 7, 6, 5, 4. Zero shows up when you want to lock something down completely, like chmod 600 ~/.ssh/id_ed25519. SSH will actually refuse a private key that's readable by others, which is a nice real-world reason to remember that one.

Execute means something different on a directory

This is the one that bit me most. On a file, x means you can run it. On a directory, x means you can enter it and reach the things inside.

So a directory with r-- lets you list the names of files but not open them. A directory with --x lets you open a file if you already know its exact name, but not list what's there. That's why web servers usually want directories at 755 and files at 644. If you chmod -R 644 a whole folder, you just removed x from every directory in it, and nothing can get inside anymore. I've done this on a live server. The site went down for about four minutes while I figured out why.

The safer pattern for fixing a tree:

find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \;

Symbolic mode is easier to read later

You don't have to use numbers at all. chmod u+x deploy.sh adds execute for the owner (u = user/owner, g = group, o = others, a = all). chmod go-w config.yml removes write from group and others. chmod +x with no letter adds execute for everyone, subject to your umask.

I use numbers when I'm setting a file to a known state and symbolic mode when I'm nudging one bit. Six months later, chmod u+x in a script is much easier to understand than chmod 744.

Ownership is the other half

Half the time Permission denied isn't about the mode at all. The file belongs to root, and you're deploy. Permissions only matter relative to who owns the file and which group it's in.

chown deploy:www-data release.sh sets both. id tells you which groups you're actually in. After you add yourself to a group, you usually need to log out and back in before it takes effect, which has wasted more of my afternoons than I want to admit.

Make it stick instead of re-Googling

Reading all this once won't hold. I've read good explanations of permissions maybe a dozen times, and each one felt clear and then evaporated within a month. What changed it for me was treating it like anything else I want to keep: save the explanation once, write my own one-line version, and get asked about it later.

I save the video or article I learned from into Recl, which pulls out the key points. Then I add my own note on top, in my words. For this topic my note says: "r=4 w=2 x=1, add per group. x on a dir = can enter. Never chmod -R 644 a folder."

A few days later the app sends a nudge, "Still remember this one?", with a small question. What does x mean on a directory? What's 640 in letters? If I get it, it comes back in about a week. If I blank, I reread my note and see it sooner.

You can do the same thing with index cards or a text file you review on Fridays. What matters is being asked again before you need it at 11pm on a broken server.

A ten-minute practice loop

1. Make a scratch folder with mkdir perms-test && cd perms-test, then touch a.txt and mkdir sub.
2. Before running each command, predict the ls -l output: chmod 640 a.txt, chmod u+x a.txt, chmod 700 sub.
3. Now run chmod 600 sub and try cd sub. It fails even for you, because the directory lost x. Put it back with chmod u+x sub.
4. Write 754 and rw-r----- on a sticky note. Tomorrow, convert each one into the other without looking anything up.

You don't need to memorize every flag chmod has. You need the owner-group-others picture and the 4-2-1 addition to still be there next time a script says Permission denied.

If you want to see what saved takeaways look like on real material, the public Recl library has a few hundred of them.

---

I'm Asutosh, and I build Recl, an app for saving videos, articles and notes, getting the key ideas, and recalling them on a schedule so they actually stick.