What this does

Converts between the three ways Linux file permissions actually get written — checkboxes, octal (755), and symbolic (rwxr-xr-x) — and shows the exact chmod command for whatever you land on. Change any one of the three and the other two update to match.

Why there are three owners, not one

Every file has exactly three permission scopes, always in this order: the owner (the user who owns the file), the group (everyone in the file's assigned group), and others (everyone else on the system). Each scope gets its own read/write/execute bits, which is exactly why 755 is three digits — one per scope — and why a directory owned by you, readable by your team, and closed to everyone else needs three different answers, not one.

What read, write, and execute actually mean on a directory

These mean something different on a directory than on a regular file, which trips people up constantly: read on a directory lets you list its contents (ls), write lets you create or delete entries inside it (notably: deleting a file only requires write access to its directory, not to the file itself), and execute lets you actually enter it (cd) or access anything inside by name. A directory with read but no execute permission is a common, confusing result: you can list filenames but not open, stat, or cd into any of them.

The special bits

setuid (leading octal digit 4, shown as s in the owner's execute position) — an executable runs with the privileges of the file's owner, not the user who launched it. passwd is the classic example: it needs to write to a file regular users can't touch directly, so it runs as root via setuid rather than making that file world-writable.
setgid (leading octal digit 2, shown as s in the group's execute position) — on an executable, runs with the file's group rather than the caller's; on a directory, every new file created inside inherits that directory's group automatically instead of the creating user's default group — the standard way to make a shared team directory actually shared.
sticky bit (leading octal digit 1, shown as t in others' execute position) — on a directory, restricts deleting or renaming files inside it to each file's own owner (or root), even when the directory itself is writable by everyone. /tmp is 1777 specifically so any user can create files there without being able to delete someone else's.

A lowercase s or t means the special bit is set and the underlying execute bit is also set; an uppercase S or T means the special bit is set but execute isn't — almost always a configuration mistake, since setuid/setgid do nothing on a file that was never executable in the first place.

FAQ

Why does chmod 777 show up as bad advice so often?

Because it grants write access to others — anyone on the system, not just you or your group — which on a real multi-user system or a web server means any other account or process can modify or replace the file. It's a debugging shortcut that works by removing the permission model entirely, not a fix for whatever permission error prompted it.

What's the difference between chmod 644 and 664?

644 (rw-r--r--) gives the group read-only access; 664 (rw-rw-r--) gives the group write access too — the difference matters specifically when multiple accounts in the same group need to edit a shared file, not just read it.

Do I need the special bits for normal use?

Rarely by hand — setgid on a shared team directory is the one an individual developer is actually likely to set deliberately; setuid and the sticky bit are mostly relevant to system binaries and system directories that are already configured correctly by the distribution.

Try it yourself

Change any field above — checkboxes, octal, or symbolic — and everything else follows.