Unix Permissions Calculator

The gap in this calculator: setuid, setgid, and the sticky bit

Type 4755 into this calculator and it computes the exact same owner/group/others breakdown as plain 755 — the leading 4 (setuid) is accepted as input but silently dropped, never shown in the symbolic output or the octal field. The same is true for setgid (2xxx) and the sticky bit (1xxx — the one that stops one user deleting another user's files in a shared directory like /tmp). If you're decoding permissions for a setuid binary or auditing a shared upload directory, this tool's output won't tell you the special bit exists. Check with ls -l instead — a leading s, S, t, or T in the permission string means a special bit is set that this calculator can't surface.

The symbolic-notation input has a quieter version of the same gap: it requires exactly nine characters from rwx-, checked position by position. A typo like xwr------ won't get rejected as invalid — it just gets silently misread according to character position, producing a plausible-looking but wrong result instead of an error.

Octal permission math, bit by bit

Each octal digit is three bits ORed together: read = 4, write = 2, execute = 1. 7 is all three (4+2+1), 5 is read + execute with no write (4+1), 6 is read + write with no execute (4+2). 755 decodes to owner = 7 (rwx), group = 5 (r-x), others = 5 (r-x). 644 decodes to owner = 6 (rw-), group = 4 (r--), others = 4 (r--) — the standard pairing for "owner edits, everyone else just reads," which is why it's the default permission for checked-in config files and HTML.

Why the execute bit means something different on a directory

On a regular file, the execute bit means "this can be run as a program." On a directory it means something unrelated: permission to cd into it and access entries inside by name. A directory with read but no execute permission lets ls list the filenames inside it, but blocks you from opening, stat-ing, or cd-ing into any of them — you can see a file exists without being able to touch it. This is also why a directory full of non-executable files (config, data, markdown) is still normally set to 755: the directory's own execute bit governs traversal, completely independent of whether the files inside are executable.

Five real chmod scenarios in production .NET deployments

1. SSH deploy keys for CI/CD. OpenSSH refuses to use a private key that's group- or world-readable, failing with a warning like "UNPROTECTED PRIVATE KEY FILE." Deploy keys for GitHub Actions or Azure DevOps pipelines need 600 — owner read/write, nothing else.
2. Kestrel behind a reverse proxy. Static files and published binaries typically want 644; the directories containing them want 755 so the web server process can traverse into them. Resist the temptation to chmod -R 777 a deployment directory to "make a permission error go away" — it grants write access to every local user on the box, including whatever else is running on that host.
3. Containerized ASP.NET Core on a non-root user. Since .NET 8, the official Linux container images run as a non-root app user by default. A bind-mounted host directory for logs or config that's owned by your host user (often UID 1000) can be unreadable or unwritable to that container user, producing an UnauthorizedAccessException at startup that looks like a code bug but is actually a UID mismatch between host and container.
4. Git only tracks one bit, not the full mode. Git records just the executable bit per file (mode 100644 vs 100755) — it has no concept of group/other permissions or special bits at all. A deploy.sh committed as 755 from one machine can clone down as non-executable on another if core.fileMode is off or the commit came through a Windows checkout, breaking a deploy script with "Permission denied" instead of a clear "file not found."
5. systemd-managed Kestrel services. If a service unit runs as a dedicated www-data-style user but the log or data directory was created manually as root (or by whoever last SSH'd in), the service fails to write logs with a permissions error that's easy to misdiagnose as an application bug rather than an ownership mismatch.

How to use this tool

1. Type either an octal value (like 755) or symbolic notation (like rwxr-xr-x) into the single input field — both are accepted, no separate toggle needed.
2. Click Calculate.
3. View the equivalent representation in the other format, plus the owner/group/others breakdown.
4. Use the octal value in your chmod command.