Chmod Calculator

Checkout cancelled · you have not been charged

Still deciding on the Linux Permissions Cheat Sheet Pack?

• Chmod cheat sheet (PDF)
• Special bits & umask (PDF)
• Command reference (PDF)
• Audit worksheet (XLSX)

• Full refund within 7 days
• Instant download
• Local currency at checkout where available
• Secure checkout by Stripe

Buy now — $5.00Try a free sheet first

What stopped you? (optional, anonymous)

The priceNot sure it fits my needPayment problemJust looking for now

Free printables

Single sheets you can print right now, no sign-up. The full pack adds every sheet in one download plus the editable files.

Printable Chmod Cheat Sheet1 page · free PDFPrintable Special Bits and Umask Chart1 page · free PDFPrintable Linux Command Reference1 page · free PDFPrintable Permissions Audit Worksheet2 pages · free PDF

Browse the free printables →

How Unix permissions work

Every file and directory on Linux, macOS and other Unix-like systems has an owner, a group and three sets of permissions: for the owner (u), for members of the group (g), and for everyone else (o). Each set can allow read (r), write (w) and execute (x). For files, read means view the contents, write means change them, and execute means run the file as a program. For directories, read means list the names inside, write means create, delete and rename entries, and execute means enter the directory and access items in it.

Numeric (octal) permissions

Each permission has a value — read 4, write 2, execute 1 — and the digit for each class is their sum. So 755 means owner 7 (rwx), group 5 (r-x) and others 5 (r-x). A fourth leading digit sets the special bits.

Common chmod values

Symbolic chmod commands

Symbolic mode is handy for changing one permission without touching the rest; numeric mode sets all of them at once.

Special permission bits

• setuid (4xxx) — when an executable runs, it runs with the file owner’s privileges. passwd uses this to update system files. Shown as s in the owner execute position.
• setgid (2xxx) — on executables, runs with the group’s privileges; on directories, new files inherit the directory’s group, useful for shared project folders. Shown as s in the group execute position.
• Sticky bit (1xxx) — on directories, only a file’s owner (or root) can delete or rename it, even if others have write access. Used on /tmp. Shown as t in the others execute position.

A capital S or T means the special bit is set but the underlying execute permission is not — usually a mistake.

Umask: default permissions

The umask removes permissions from the defaults used when files and directories are created. New files start from 666 and directories from 777, and the umask bits are cleared. With the common umask 022, new files get 644 and directories 755; with 077, files get 600 and directories 700 — private to the owner. Check your umask with the umask command and set it in your shell profile or service configuration.

Worked example: a web server

For a website served by a web server running as a different user, a common layout is directories at 755 and files at 644, owned by the deploying user. Scripts that must run are 755. Configuration files containing database passwords are 640 with the web server’s group, or 600 if only the owner needs them. Running find /var/www/site -type d -exec chmod 755 {} + and find /var/www/site -type f -exec chmod 644 {} + applies this safely, rather than a blanket chmod -R 777, which would let any process on the server modify the site.

Security tips

• Avoid 777 and world-writable files; they let any user or compromised process change them.
• Keep private keys at 600 and the .ssh directory at 700 — SSH refuses keys with loose permissions.
• Use groups to share access instead of opening permissions to everyone.
• Audit setuid programs; a vulnerable setuid binary can give attackers root.
• Remember that permissions do not apply to root, and that directory permissions control deleting files inside them.

Permissions on directories vs files

Directory permissions often surprise people. To open a file, you need execute permission on every directory in its path, even if the file itself is readable. Read permission on a directory without execute lets you list names but not open anything inside; execute without read lets you open files whose names you already know but not list the directory. Deleting a file depends on write and execute permission on the directory that contains it — not on the file’s own permissions — which is why the sticky bit exists for shared directories.

Troubleshooting “Permission denied”

1. Check who you are running as: whoami and id show your user and groups.
2. Check the file and every parent directory with ls -ld.
3. Make sure the process has execute permission on each directory in the path.
4. For scripts, confirm the file has execute permission and a valid shebang line such as #!/bin/bash.
5. Remember that new group memberships take effect after you log out and back in.
6. On some systems, extra layers such as ACLs (getfacl), SELinux or AppArmor can deny access even when mode bits allow it.

Privacy

The calculator runs in your browser; nothing is sent anywhere.