Three letters, three numbers — and once the math clicks, chmod stops feeling like a guessing game.
Reading the output of ls -l #
-rwxr-xr-- 1 alice developers 120 Sep 15 app.shBreak the permission string into four pieces:
– rwx r-x r–
│ │ │ │
│ │ │ └── Others
│ │ └─────── Group
│ └──────────── Owner
└──────────────── Type (- = file, d = directory)
Each group is some combination of read, write, and execute. For a directory specifically, execute means “you’re allowed to enter/traverse it” — not run it like a program.
The numbers behind the letters #
Linux represents each permission group as a single digit, by just adding up values:
| Permission | Value |
|---|---|
r read | 4 |
w write | 2 |
x execute | 1 |
So rwx = 4+2+1 = 7. r-x = 4+0+1 = 5. r-- = 4+0+0 = 4.
755 — the classic “executable script” permission #
7 5 5
│ │ │
│ │ └── Others → r-x
│ └─────── Group → r-x
└──────────── Owner → rwx
Owner can read/write/execute; everyone else can read and execute, but not modify. Perfect for a script you want others to run but not tamper with.
644 — the classic “ordinary file” permission #
Owner gets read + write, everyone else gets read-only. This is the default most regular files should have.
Changing permissions and ownership #
chmod 755 script.sh # → rwxr-xr-x
chmod 644 config.txt # → rw-r--r--
chown alice file.txt # change owner
chown alice:developers file.txt # change owner + groupThis matters constantly in DevOps: applications often run under a specific, restricted Linux user, and a misconfigured owner or permission is one of the most common reasons a working deployment suddenly can’t read its own files.
