Unix permissions are three groups of three bits: read worth four, write worth two and execute worth one, added together for the owner, the group and everyone else. That is why 755 and 644 appear everywhere — 7 is all three, 6 is read plus write, 5 is read plus execute. Tick the boxes or type the number and both the numeric and symbolic forms are produced together, along with the command to run.
A fourth leading digit sets the special bits, and they change the symbolic form rather than adding to it: setuid and setgid replace the execute letter with an s, the sticky bit with a t, and a capital letter where execute is not set at all — which is a state worth noticing, since it usually means the permission was written wrongly.
Values worth knowing by heart
-
644 for files, 755 for directories:
the usual defaults. A directory needs execute to be entered at all, which is why the two differ, and it is the reason a directory set to 644 appears to vanish.
-
777 is almost never the right answer:
it lets anyone with an account write to the file. It is the reflex fix for a permissions error and it is nearly always the wrong one — the real problem is usually ownership.
-
Execute on a directory means something different:
on a file it means the file can be run. On a directory it means the directory can be entered and its contents reached.
-
The sticky bit matters on shared directories:
with it set, only a file's owner can delete it, which is what makes a world-writable temporary directory safe to share.
Three bits, three groups, and where 755 actually comes from
Unix permissions break down into three groups of three bits each — owner, group and everyone else — where read is worth four, write is worth two, and execute is worth one, added together within each group. That arithmetic is the entire reason 755 and 644 show up everywhere: 7 is all three bits together, 6 is read plus write, 5 is read plus execute. The [msm_tool slug="chmod-calculator"] produces the numeric form, the symbolic form, and the actual command to run, all from the same input.
644 for files, 755 for directories
Those are the ordinary defaults, and the difference between them exists for a specific reason: a directory needs its execute bit set just to be entered at all, independent of whether it is readable. A directory left at 644 behaves as though it has vanished, because nothing can actually step inside it without that bit.
Execute means something different on a directory
On a file, execute means the file can be run directly. On a directory, it grants the right to enter that directory and reach whatever is inside it — a genuinely different permission wearing the same name, which is easy to assume works the same way in both places until a directory that is readable but not executable turns out to be effectively empty from the outside.
777 is almost never the actual fix
Setting everything wide open lets anyone with an account on the system write to the file, and it is the reflex response to a permissions error that is nearly always wrong. The real cause underneath a permissions error is usually ownership rather than the permission bits themselves, and 777 papers over that problem instead of addressing it.
The fourth digit replaces a letter, it does not add one
A leading fourth digit sets the special bits — setuid, setgid and sticky — and each one changes the symbolic form rather than appending anything new to it: the execute letter is replaced with an s, or with a t for the sticky bit. Where a capital letter appears instead of lowercase, that specific combination means the special bit is set while execute itself is not, which is a state worth double-checking rather than assuming was intentional.
Where the sticky bit actually matters
Set on a shared, world-writable directory, the sticky bit restricts deletion so that only a file's own owner can remove it, regardless of who else can write to that directory. That single bit is what makes a shared temporary directory usable without one person being able to delete everyone else's files.