Understanding Linux file permissions and umask, for people who always just chmod 777
chmod 777 makes the permission error go away. It also makes the file writable and
executable by literally everyone on the system, which is almost never what the situation
actually needed. Here's what the numbers mean and what to use instead.
The three permission groups
Every file has three sets of permissions: owner, group, and others (everyone
else). Each set has three possible permissions: read (r), write (w), execute
(x). ls -l shows all nine as a string like rwxr-xr--:
rwxr-xr--
│││││││└└─ others: r-- (read only)
││││└└──── group: r-x (read + execute)
└└└─────── owner: rwx (read + write + execute)
Where the numbers come from
Each permission triplet is a sum: read = 4, write = 2, execute = 1. rwx = 4+2+1 = 7.
r-x = 4+0+1 = 5. r-- = 4+0+0 = 4. So chmod 754 file sets owner to rwx (7), group to
r-x (5), others to r-- (4) — and chmod 777 sets all three groups to full
read/write/execute, which is the "make the error disappear" move that also means anyone
with any access to the system can modify or execute the file.
Common values worth actually knowing instead of guessing:
| Value | Meaning | Typical use |
|---|---|---|
| 644 | owner rw, group r, others r | Regular files — configs, source code |
| 755 | owner rwx, group rx, others rx | Executable scripts, directories |
| 600 | owner rw, nothing for anyone else | Private files — SSH keys, credentials |
| 700 | owner rwx, nothing for anyone else | Private directories |
What umask actually controls
umask doesn't set permissions directly — it's a mask that subtracts from the default
permissions new files get when created. The default before masking is 666 for files
(read+write, no execute) and 777 for directories. A umask of 022 (the common default)
removes write access for group and others, landing new files at 644 and new directories
at 755 — which is exactly why those are the defaults you see everywhere without anyone
setting them explicitly.
umask # show the current mask
umask 027 # new files: 640, new directories: 750 — tighter than default
This matters specifically for anything that creates files programmatically — a service that writes logs, a script that generates output files — since those inherit whatever umask the creating process is running under, not a value you set on the file afterward.
Why 777 specifically is the wrong reflex
Setting 777 doesn't just fix "my process can't write this file" — it also grants execute
permission (relevant for scripts) and, critically, write access to others, meaning any
other user or process on a shared system can modify or replace that file. The fix for "my
process can't access this file" is almost always to give the specific owner or group that
actually needs access the specific permission it needs (usually 644 or 755, sometimes
adjusting ownership with chown instead of permissions at all) — not opening it to
everyone.
Sources: POSIX/Linux chmod and umask semantics (man chmod, man umask, man 2
umask); standard default permission values (666/777 before masking) as documented in the
GNU coreutils manual.