Three digits, each from 0 to 7, control who can read, write, or execute a file on any Unix-like system — Linux servers, macOS, most hosting control panels. chmod 755 is probably the most-copied command in every deployment tutorial ever written, usually without an explanation of what the 7, the 5, and the second 5 actually mean, or why getting one of them wrong on the wrong file is a real security problem rather than a cosmetic one.

Three Digits, Three Owners, Four Permission Levels

Every file has three permission groups — owner, group, and others — and each group gets a single digit built from three bits: read (4), write (2), and execute (1).

Permission Digit = Read(4 if granted) + Write(2 if granted) + Execute(1 if granted)

Add whichever of the three apply, and the sum is that group's digit. Full access is 4+2+1 = 7. Read and execute without write is 4+1 = 5. Read-only is 4. A three-digit permission string like 755 means: owner gets 7 (full access), group gets 5 (read and execute, no write), others get 5 (same as group).

Why 755 and 644 Show Up Everywhere

755 (rwxr-xr-x): the default for directories and executable scripts. The owner can read, write, and execute or enter the directory; everyone else can read and execute or enter it, but not modify it. This is why nearly every web server directory and every shell script you download ends up at 755 — it is the minimum permission that lets the file actually run while keeping write access restricted to the owner.

644 (rw-r--r--): the default for regular files that do not need to execute — HTML, CSS, images, configuration files meant to be readable but not run. The owner can read and write; everyone else can read but not modify or execute.

600 (rw-------): owner-only read and write, nothing for group or others. This is the correct permission for SSH private keys, .env files holding database credentials, and anything else that should be unreadable to any other user on a shared system — a private key left at 644 is readable by every other account on that machine.

Reading the Symbolic Notation

The symbolic form — the string ls -l prints, like -rwxr-xr-x — carries the same information as the octal digits in a more visual form. The leading character marks the file type (- for a regular file, d for a directory). The next nine characters come in three groups of three: owner, group, others, each written as r, w, x in that fixed order, with a dash standing in for any permission not granted.

Special permission bits — SUID, SGID, and the sticky bit — modify the execute position in that notation rather than adding a tenth character. A file with SUID set shows a lowercase s in the owner's execute slot if execute is also granted, or an uppercase S if it is not. The same pattern applies to SGID in the group slot and the sticky bit (lowercase t or uppercase T) in the others slot — the case tells you whether the underlying execute bit is also set, at a glance, without checking the octal separately.

What SUID, SGID, and the Sticky Bit Actually Do

These three special bits add a fourth leading digit to the octal form — 4 for SUID, 2 for SGID, 1 for sticky — and each does something distinct from the basic read/write/execute model.

SUID (Set User ID, digit 4): when set on an executable file, the program runs with the permissions of the file's owner, not the user who launched it. The classic example is passwd, which needs to write to a system file regular users cannot normally touch directly — SUID lets it do that safely within a controlled program, rather than requiring every user to have direct write access to the system file itself.

SGID (Set Group ID, digit 2): on an executable, it runs with the file's group permissions. On a directory, it has a different and more commonly used effect: new files created inside automatically inherit the directory's group, rather than the creating user's default group — useful for a shared project folder where multiple users need files to stay owned by the same group regardless of who created them.

Sticky bit (digit 1): on a directory, it restricts deletion so that only a file's owner (or the directory's owner, or root) can delete or rename it, even if other users have write access to the directory. /tmp is the standard example — many users and processes need to write files there, but none of them should be able to delete each other's files.

A Permission Mistake That Is Easy to Make and Costly

Setting a sensitive file — an SSH private key, a database credentials file, an API secret — to 644 or wider instead of 600 is one of the more common permission mistakes, because 644 is the default for so many other files that it is easy to apply out of habit without checking whether the specific file actually needs group or other read access. On a shared or multi-user system, that mistake makes the file readable by every other account, not just the intended owner — the fix is a single chmod 600 command, but only once someone notices the file was ever set wider than it should have been.

Frequently Asked Questions

What does chmod 777 mean, and why is it usually a bad idea?

777 grants full read, write, and execute access to the owner, group, and every other user on the system — effectively no restriction at all. It is sometimes used as a quick fix for a permissions error, but it removes the access control the permission system exists to provide, and on a shared or internet-facing system it means any other user or process can modify or replace the file.

Why do directories need the execute bit to be usable, not just read?

The execute bit on a directory controls whether a user can enter it and access files inside by name, separate from whether they can list its contents. A directory with read but no execute permission lets a user see filenames inside it (if they already have another way to list them) but not actually open or access any file inside — which is why 644 is correct for files but will not work as a directory permission the way 755 does.

Does changing a file's permissions affect who owns it?

No — chmod changes what the existing owner, group, and others are allowed to do, not who the owner or group actually is. Changing ownership itself requires a separate command (chown), run by root or, for some operations, the current owner.

Why does SUID matter less on scripts than on compiled binaries?

Most modern Unix-like systems ignore the SUID bit on shell scripts specifically, as a security measure against a well-known class of exploit involving script interpreters. SUID still functions as intended on compiled binaries, which is why system utilities like passwd are compiled executables rather than scripts.

What permission should a web-accessible upload directory use?

This depends on the server configuration, but a common safe baseline is 755 for the directory itself (so the web server process can enter and read it) with uploaded files not granted execute permission, specifically to prevent an uploaded file from being run as a script if an attacker manages to upload one disguised as an image or document.

Build your own permission set — special bits included — and get both the octal and symbolic notation instantly with the Chmod Calculator.