What chmod 755 Actually Means (and Why 777 Isn't the Fix)

Something breaks at 11pm. A script that ran fine yesterday prints Permission denied, and a small voice in the back of your head says: just chmod 777 it. I have been that voice. It works maybe a third of the time, and every time it works you learn nothing and leave a file behind that anyone on the box can rewrite.

Every file and directory on a Linux or macOS system carries nine permission bits, stored alongside its owner and its group. They decide who can read it, who can change it, and who can run it. chmod is the command that sets them, and 755 is the number people paste into a terminal without knowing what they just said. If your whole relationship with files runs through a graphical editor or IDE, these bits stay invisible right up until the day they aren't.

Here's the thing worth internalizing. 755 is not a number. It is nine switches written in shorthand. Once you see the three groups of three, you never look it up again.

Three groups of three, and the numbers 4, 2 and 1

The nine bits split into three classes of user, always in the same order: the owner of the file, the group the file belongs to, and everyone else. Inside each class there are three switches, also always in the same order: read, write, execute.

Each switch gets a value. Read is 4, write is 2, execute is 1.^[1] Those aren't arbitrary, they're the place values of three binary digits, so any combination of the three sums to a unique number between 0 and 7. That is exactly one octal digit per class, which is why a chmod number is three digits long.

So 755 says the owner can read, write and execute; the group can read and execute but not write; everyone else gets the same as the group. 644 says the owner can read and write, and nobody else can do anything but read. 600 says the owner can read and write and the rest of the machine is locked out entirely.

Reading ls -l one character at a time

The other half of the skill is reading the output rather than writing the input. Here is a real directory listing from my machine:

$ ls -l
-rwxr-xr-x 1 drago drago 18 Sep  5 01:29 deploy.sh
drwxr-xr-x 2 drago drago 40 Sep  5 01:29 newdir
-rw-r--r-- 1 drago drago  0 Sep  5 01:29 notes.md
drwx------ 2 drago drago 40 Sep  5 01:29 private

Ten characters on the left of each row. The first one is not a permission at all, it is the file type: - for a regular file, d for a directory, l for a symbolic link, plus s, p, b and c for sockets, pipes and devices. The kernel stores that in the same 16-bit field as the permissions, above them: 0100000 marks a regular file, 0040000 a directory, 0120000 a symlink.^[4]

The remaining nine are the three groups, left to right, owner then group then other, and inside each group it is always rwx in that order with a dash for a switch that is off. So -rwxr-xr-x is a regular file at 755 and drwx------ is a directory at 700. Two columns over, the two names are the owning user and the owning group, which is what decides which of the three groups applies to you.

On a directory, x means traverse, not run

This is where the mental model most people build quietly goes wrong. On a regular file, the execute bit means the kernel will run this. On a directory it means something else entirely: search permission, the right to look up a name inside the directory and pass through it. GNU's own chmod documentation spells it out in the definition of the letter: execute, or search for directories.^[2]

Read and execute are genuinely separate powers on a directory, and separating them produces one of the strangest outputs in Unix. I set a directory to 644, which gives read without search, and ran three commands:

$ chmod 644 reports
$ ls -ld reports
drw-r--r-- 2 drago drago 60 Sep  5 01:29 reports

$ ls reports
q3.csv

$ ls -l reports
total 0
-????????? ? ? ? ?            ? q3.csv

$ cat reports/q3.csv
cat: reports/q3.csv: Permission denied

Look at what happened there. ls printed the filename, because listing names is a read of the directory itself. Then ls -l printed a row of question marks, because getting the size and the mode of q3.csv means looking that name up through the directory, and that is search. And cat failed outright, even though q3.csv is mine and sits at -rw-r--r--, unchanged and perfectly readable, one level down.

The first time I saw that -?????????line I assumed the filesystem was corrupt. It isn't. It is the kernel telling you, in the least helpful way available, that it could see the name and could not follow it.

Most permission denied errors are about a directory

That demo is a toy, but the mechanism behind it is the single most useful thing in this article. When you open a file, the kernel does not jump to it. It resolves the path one component at a time, and it needs search permission on every directory it walks through. From path_resolution(7): if the process does not have search permission on the current lookup directory, an EACCES error is returned.^[3] The open(2) manual says the same thing from the other end, defining EACCES as the requested access not being allowed or search permission being denied for one of the directories in the path prefix.^[7]

There is a one-line diagnostic for this and hardly anyone uses it. namei -l takes a path and prints the mode of every component, so the guilty directory identifies itself:

$ namei -l reports/q3.csv
f: reports/q3.csv
drw-r--r-- drago drago reports
                        q3.csv - Permission denied

$ chmod 755 reports
$ namei -l reports/q3.csv
f: reports/q3.csv
drwxr-xr-x drago drago reports
-rw-r--r-- drago drago q3.csv

Symbolic mode is usually the one you should type

Octal is absolute. It sets all nine bits at once and throws away whatever was there. Symbolic mode changes one thing and leaves the rest alone, which is what you normally want. The grammar is three parts: who, an operator, and which permissions. Who is u for the owning user, g for the group, o for others, and a for all. The operator is + to add, - to remove, and = to set exactly, clearing anything unmentioned.^[2]

chmod u+x deploy.sh      # give the owner execute, touch nothing else
chmod go-w shared.conf   # take write away from group and other
chmod a=r LICENSE        # everyone reads, nobody writes, nobody executes
chmod -R u+rwX,go+rX .   # capital X: directories get search, files don't get execute

That last line is the one to steal. The capital X means execute or search only if the file is a directory or already has execute permission for some user.^[2] It exists precisely because chmod -R 755 on a source tree marks every README, every JSON file and every image as an executable program. That is a small act of vandalism you then commit to git. chmod -R u+rwX,go+rX is what people mean when they type the other thing.

umask decides what new files get, by subtraction

Nobody runs chmod on every file they create, so something else picks the defaults. That something is the umask, a per-process mask of bits to turn off. The permissions listed in the umask are removed from whatever mode a program asks for when it creates a file.^[5]

The typical default is 022.^[5] A program creating a regular file asks for 0666, the mask clears the two write bits, and you get 0644. A program creating a directory asks for 0777 and gets 0755. The arithmetic in the manual is exact: 0666 & ~022 = 0644.^[5]

$ umask
0022

$ touch newfile.txt && mkdir newdir && ls -l
drwxr-xr-x 2 drago drago 40 Sep  5 01:29 newdir
-rw-r--r-- 1 drago drago  0 Sep  5 01:29 newfile.txt

The fourth digit: setuid, setgid and the sticky bit

Above the nine bits sit three more, and they take a fourth octal digit in front: 4000 for set user ID, 2000 for set group ID, 1000 for the sticky bit.^[1] Same 4-2-1 pattern, one level up.

setuidmakes a program run as the file's owner rather than as you.^[2] The canonical example is on every Linux box:

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 93640 Feb  2  2026 /usr/bin/passwd

$ ls -ld /tmp
drwxrwxrwt 5903 root root 121960 Sep  5 01:29 /tmp

The ssits where the owner's execute bit is printed. It is there because changing your password means writing /etc/shadow, a file you have no business writing, so the program runs as root for the duration. Powerful, and a foothold if you ever set it on something you wrote yourself.

setgid on a directory is the friendliest of the three. A new file normally takes the group of the process that made it. With 2000 on the parent directory, Linux uses BSD semantics instead and new files inherit the group of the directory.^[4] That is how a shared project folder stays shared:

$ chmod 2775 shared && ls -ld shared
drwxrwsr-x 2 drago adm 40 Sep  5 01:29 shared

$ touch shared/inherited.txt && ls -l shared/
-rw-r--r-- 1 drago adm 0 Sep  5 01:29 inherited.txt

$ touch plain/notinherited.txt && ls -l plain/
-rw-r--r-- 1 drago drago 0 Sep  5 01:29 notinherited.txt

The sticky bit is why /tmp works. /tmp is mode 1777: literally everybody can write to it. The only thing standing between that and chaos is the t at the end, which means a file in that directory can be renamed or deleted only by the owner of the file, by the owner of the directory, or by a privileged process.^[4] Without it, world-writable would mean anyone could delete anyone's work. POSIX declares the effect of t on anything other than a directory to be unspecified, so it is a directory feature in practice.^[6]

Why 777 is the wrong fix, and what to do instead

chmod 777 is a sentence with a meaning, and the meaning is: every account on this machine may read, modify and run this file. Not just you. The web server process. The build agent. Whatever an attacker lands as after finding a hole in something unrelated. On a script it is worse than data exposure, because an attacker who can rewrite the file gets to choose the code that runs the next time cron fires. Least privilege is not an abstract principle here, it is a concrete checklist item you either did or didn't do.

And here is the part that should end the habit on its own: it usually doesn't even work. If the real problem is a missing search bit on a parent directory, chmod 777 the-file changes a mode the kernel never gets far enough to read.

What to do instead, in order:

1. Run namei -lon the full path and read down the list. The first line that isn't readable to you is your answer.
2. Check who you actually are with id, and compare it to the owner and group columns in ls -l. A surprising share of permission problems are ownership problems, fixed with chown or chgrp, not chmod.
3. If it is running in a container, check the user ID inside the image against the one on the host volume. Bind mounts pass numeric user IDs straight through, and the way containers share the host kernel rather than emulating a machine is exactly why a uid 1000 mismatch shows up as a permission error.
4. Then set the narrowest mode that works. 755 for directories and things meant to run, 644 for everything else, 600 for anything holding a secret, and g+w plus setgid when a team genuinely needs shared write.

Nine switches, three groups, 4-2-1, and one rule that saves you the most time: when the file looks fine and the error persists, look up the tree. Go run namei -lon the next thing that breaks. You'll find it in about four seconds.