Skip to content
ansezz.

▸ Free tool

Chmod Permissions Calculator.

Tick the boxes or type the number — both directions stay in sync. Includes the setuid, setgid, and sticky bits, with the S/T rendering everyone else gets wrong.

▸ Runs offline

Every digit is computed in this tab. No request, no upload, no logging — paste a real path if you want to.

Permission bits for owner, group, and others
Class Read 4 Write 2 Execute 1 Digit
Owner u 0
Group g 0
Others o 0

▸ Special bits (the optional 4th digit) — now 0

▸ Mode

755

4-digit: 0755

▸ Symbolic

rwxr-xr-x

ls -l: -rwxr-xr-x · drwxr-xr-x

▸ In plain English

Owner can read, write, and execute; group and others can read and execute.

    ▸ Command

    chmod 755 path/to/file

    Symbolic: chmod u=rwx,g=rx,o=rx path/to/file

    How the octal actually works

    Each digit is a three-bit field: read is 4, write is 2, execute is 1, and you add them. So 7 is rwx, 6 is rw-, 5 is r-x. The three digits are owner, group, others — in that order, and the kernel checks them in that order and stops at the first class you match. That trips people up: if you own a file with mode 077, you get nothing. Your group membership never gets consulted, because you already matched as the owner.

    A fourth digit sits in front for the special bits. This calculator treats the checkboxes and the number as one value in two shapes: ticking a box ORs a bit into the digit, typing a digit sets the boxes. It also right-aligns short input the way chmod does — chmod 7 file is 0007, which grants rwx to everyone except the owner and the group. Type all three digits.

    Execute on a directory does not mean "run"

    Same three bits, completely different meanings depending on what you point them at. This is the single biggest source of "but I gave it permission" bugs.

      On a file On a directory
    r (4) Read the contents. List the names inside it (plain ls).
    w (2) Change the contents. Create, rename, and delete entries inside it.
    x (1) Run it as a program. Traverse it — cd in, and reach anything below.

    Two consequences worth internalising. Read without execute on a directory lets you see the names but not stat them, so ls -l returns question marks. And write on a directory is delete permission for everything inside it: you can remove a file you have no write access to, as long as you can write its parent. That is exactly why /tmp needs the sticky bit.

    Why 777 is almost always wrong

    777 is a symptom, not a fix. It says "I don't know which account needs this, so I'll give it to all of them" — including the web server, the queue worker, and whatever a future attacker lands as. World-writable plus world-executable on a deployed application means one file-upload bug is a shell, and the audit trail is worthless because every process could have written the file.

    The correct move is nearly always ownership. Work out which user the process actually runs as, chown the tree to it, then use 750 for directories and 640 for files. If two services need the same tree, give them a shared group and a setgid directory (2775) so new files inherit that group automatically. Reserve world-write for scratch directories that carry the sticky bit.

    umask: why new files are 644

    You never actually create a file at 666. The kernel starts a new file at 666 and a new directory at 777, then clears whatever bits the process umask names. The common umask of 022 clears group and other write, which is where 644 and 755 come from. Set it to 077 and you get 600 and 700 — the right default for anything holding secrets.

    umask only ever removes bits, never adds them, which is why a freshly written script is never executable and always needs a chmod +x. It is also per-process and inherited by children, so setting it in your shell profile does nothing for a systemd service — use UMask= in the unit file instead.

    The special bits, and setuid risk

    Setuid (4000) makes a binary run as the file's owner instead of the caller. Setgid (2000) does the same for the group, and on a directory it makes new entries inherit that directory's group. The sticky bit (1000) on a directory restricts renames and deletes to each entry's owner — /tmp is 1777 for precisely that reason. When the matching execute bit is missing the letter goes uppercase: S, S, T. That is not a special mode, it is a warning sign.

    Linux ignores setuid and setgid on interpreted scripts entirely, so chmod 4755 deploy.sh buys you nothing except a finding in the next audit. On a compiled binary the bit is real, and so is the blast radius: every bug in that program becomes a bug that runs as its owner. Reach for a sudo rule or a file capability such as cap_net_bind_service first. One last trap: GNU chmod preserves a directory's setuid and setgid bits when you pass three digits — pass four (0755) when you actually want them cleared.

    Questions people ask

    What does chmod 755 mean?

    755 gives the owner read, write, and execute (7 = 4+2+1) and gives the group and everyone else read and execute (5 = 4+1). In symbolic form that is rwxr-xr-x. It is the normal mode for directories and for scripts other accounts need to run.

    What is the difference between chmod 755 and 644?

    The execute bit. 644 is rw-r--r--, for data files nobody needs to run. 755 is rwxr-xr-x, which adds execute. On a directory the execute bit means permission to enter it, so directories are usually 755 while the files inside them are 644.

    Is chmod 777 ever safe?

    Almost never on a server. 777 lets every local account and every process — including a compromised web server — read, modify, and execute the file. If something only works at 777, the real problem is ownership: fix the user or group with chown, then use 750 or 640.

    What does the 4 in chmod 4755 do?

    The fourth digit holds the special bits: 4 is setuid, 2 is setgid, 1 is sticky. 4755 sets setuid, so the program runs with the file owner's privileges instead of the caller's. Linux ignores setuid on shell scripts, and on a compiled binary it is a real privilege-escalation risk.

    Why does my permission string show a capital S or T?

    A capital letter means the special bit is set but the matching execute bit is not. rwSr--r-- is setuid with no owner execute; drwxrwxrwT is the sticky bit with no other execute. Lowercase s or t means both bits are on. A capital is usually a mistake — the bit is stored but nothing can use it.

    How do I chmod a folder and everything inside it?

    chmod -R 755 dir works but marks every data file executable too. Use two passes instead: find dir -type d -exec chmod 755 {} + then find dir -type f -exec chmod 644 {} +. Or use the capital X flag, as in chmod -R u=rwX,go=rX dir, which adds execute only to directories and to files that already had it.

    Related

    Keep reading