Chmod Calculator

Each digit is read(4) + write(2) + execute(1). The three digits are owner, group, others. So 755 = owner 7 (rwx), group 5 (r-x), others 5 (r-x). Directories need the execute bit (x) to be traversable — that is why 644 on a directory makes it inaccessible.

Most chmods are three digits, but the mode can take a fourth. The leading digit is the special-bits octet, and it redefines the position it occupies.

• 4 — setuid. The program runs with the permissions of its owner instead of the user who invoked it. /usr/bin/passwd is mode 4755 for exactly this reason: anyone may run it, but it can only rewrite /etc/shadow because it briefly becomes root. Note that setuid on a shell script does nothing on Linux — the kernel ignores the bit, which surprises people who test it and conclude the feature is broken.
• 2 — setgid, on a directory. This is the bit that still earns its keep. Files created inside a setgid directory inherit the directory's group rather than the creator's primary group. A shared /srv/project at 2775 means every teammate's output stays group-readable without anyone running chgrp afterwards. Without it you get the familiar shared-directory mess where half the files belong to the wrong group and nobody can tell why.
• 1 — sticky. When set on a directory, only a file's owner (or root) may delete or rename it, even though everyone can write there. /tmp is 1777 for this reason. A 777 directory without the sticky bit lets any user delete any other user's files, which is a quiet way to break a multi-tenant machine.

Related, and usually confused with chmod: umask is why new files appear as 644 and not 666. The kernel starts from the maximum (666 for files, 777 for directories) and subtracts the umask. With the conventional umask 022, 666 becomes 644 and 777 becomes 755. If a process creates files that are group-writable without you asking, the umask of that process is the thing to change — chmod on the parent directory will not help.

chmod -R 755 on a source tree. The recursive flag applies one mode to everything, files and directories alike, so every file underneath becomes executable. What you actually want is 644 for files and 755 for directories. The symbolic form does that in one pass: chmod -R u=rwX,go=rX. A capital X sets execute only where it is already set, or where the target is a directory.

SSH keys that are too open. ssh refuses a private key any other user can read, with the message Permissions 0644 for 'id_rsa' are too open. The expected mode is 600 on the key and 700 on ~/.ssh. This is the rare case where a group-read bit is a hard failure rather than a style question.

777 as a debugging move. Making a directory world-writable to silence a permission error usually means the real cause is ownership, or a missing execute bit on a parent directory in the path. What you get instead is a directory anyone can drop a file into — and on a web root that is a direct route to running someone else's code. CI scanners flag it because the failure mode is severe, not because the number is unlucky.

Expecting Git to track modes. Git records exactly one permission bit: whether a file is executable. Everything enters the index as 100644 or 100755, and nothing else. Group and other permissions are not versioned at all, so a checkout on another machine can produce a mode you never set. core.fileMode=false hides that difference; it does not resolve it.

See also: Cron Expression Tester · Hash Generator · Password Generator · DevOps Utilities · Security & SRE