chmod Permissions Calculator
Convert Linux permissions between checkboxes, octal and ls notation, with special bits and a umask calculator. Gives you the chmod command ready to paste.
As ls -l shows it
rw-r--r--
Type a value here and the checkboxes follow. Accepts 755, 0755, 4755 or rwxr-xr-x.
Permissions
| Read(r) | Write(w) | Execute(x) | # | |
|---|---|---|---|---|
| Owner | 6 | |||
| Group | 4 | |||
| Others | 4 |
Each permission is worth a number: read 4, write 2, execute 1. They are added per group.
Special bits
Ready-to-paste commands
chmod 644 archivochmod u=rw,g=r,o=r archivochmod -R 644 directorio/Common values
umask calculator
umask is not subtracted from permissions: it is applied as a mask that removes them. That is why umask 013 leaves a file at 664 and not 653.
A new file is created as
644
rw-r--r--
A new directory is created as
755
rwxr-xr-x
The system asks for 666 for files; it never grants x on its own. For directories it asks for 777.
x on a directory does not mean “execute”
On a file, x means execute. On a directory it means being able to traverse it. A directory with r but no x lets you see the list of names but open nothing inside; with x but no r it lets you reach a known path but not list it. This is the most common cause of a 403 on a web server.
What this tool does
It translates file permissions on Linux, macOS and any POSIX system between the three ways they are written: checkboxes, octal (755) and ls -l notation (rwxr-xr-x). Change any of the three and the other two follow, and below you get the chmod command ready to copy.
It also covers two things almost no online calculator includes, and they are exactly where people get it wrong: the special bits (setuid, setgid, sticky) and a umask calculator that actually applies the mask instead of subtracting.
How to use it
- Tick the boxes, or type the value straight into the octal field.
- The octal field accepts
755,0755,4755and alsorwxr-xr-xor the whole linels -lprints. - Copy whichever command you need: numeric, symbolic or recursive.
How permissions are read
A POSIX permission answers two questions: who, and what they can do.
They are defined by POSIX, so they behave the same on Linux, macOS and BSD. The who is three groups, in this order: the file’s owner, the group it belongs to, and everyone else. The what is three permissions, each worth a number:
| Permission | Letter | Value |
|---|---|---|
| Read | r | 4 |
| Write | w | 2 |
| Execute | x | 1 |
The values are added within each group, producing a digit from 0 to 7. Three groups, three digits:
755= owner 7 (4+2+1, everything), group 5 (4+1), others 5 (4+1) →rwxr-xr-x644= owner 6 (4+2), group 4, others 4 →rw-r--r--600= owner 6, nobody else anything →rw-------
755 and 644, and why they are the two most used values
The only difference between them is the execute bit, and the rule on a web server is short:
- 644 for files. An
.html, a.php, an image or a.cssdo not need to be executed. The server reads and serves them. - 755 for directories. A directory does need the
xbit, but not for the reason it looks like.
The trap of x on a directory
This is where most time gets lost, and it is worth being clear about because it explains most “impossible” 403s.
On a file, x means execute: you can run it as a program.
On a directory, x means traverse: you can enter it and reach what is inside. It has nothing to do with executing anything.
The consequences are unintuitive:
- Directory with
rbut nox: you can list the file names, but you cannot open any of them.lsworks,catfails. - Directory with
xbut nor: you cannot list the contents, but you can open a file if you know its exact name. This is the basis of the “hidden but reachable” directory trick. - And
xis needed on every directory along the path. If/var/www/html/is fine but/var/www/has noxfor the server user, nothing inside gets served.
When a file has correct permissions and still returns 403, the problem is almost always in a parent directory, not in the file.
The special bits
A fourth digit fits in front of the octal, for three bits that change behaviour:
| Bit | Value | What it does |
|---|---|---|
| setuid | 4 | The program runs as the owner, not as whoever launched it |
| setgid | 2 | On a directory, whatever is created inside inherits its group |
| sticky | 1 | On a shared directory, each user can only delete their own files |
Where they actually show up:
1777is/tmp. Everyone writes, but nobody deletes anyone else’s files. Without the sticky bit,/tmpwould be a disaster.2775on a team folder makes new files inherit the project group instead of the primary group of whoever created them. It is the correct way to set up a shared directory.- setuid is best avoided. A root-owned setuid binary with any flaw is a direct privilege escalation. It is one of the first things an attacker looks for with
find / -perm -4000.
How they appear in ls
The special bits have no column of their own: they sit on top of the x of the matching group. And the detail that catches people out is that the letter changes case depending on whether the x they cover was set:
rwsr-xr-x→ setuid with execute (4755)rwSr-xr-x→ setuid without execute (4655); the capital S warns that the bit is set but uselessrwxrwxrwt→ sticky with execute (1777)rwxrwxrwT→ sticky without execute (1776)
A capital letter there almost always means someone set the special bit and forgot the execute one.
umask, which is not a subtraction
umask decides the permissions a new file is born with. The explanation that circulates everywhere is “it is subtracted from 666 or 777”, and it works just well enough that nobody corrects it.
What it really does is apply as a bit mask that removes permissions:
result = base AND NOT umask
And the base is not the same for everything:
- Files are requested with 666. The system never grants
xto a file on its own, precisely so a downloaded file is not born executable. - Directories are requested with 777, because without
xthey could not be traversed.
With umask 022, the common one: a file is born 644 and a directory 755 — exactly the two values from the web server rule.
Where subtracting and masking diverge: with umask 013, subtracting would give 666 - 013 = 653. The real mask gives 664. The 1 in the umask removes the execute bit, which base 666 never had, so it removes nothing; subtracting discounts it anyway and produces a number that does not exist.
Common mistakes
chmod 777to “fix it”. If something only works with 777, the problem is ownership, not permissions. The right move ischownto the web server user and leave 644/755.chmod -R 755over the whole project. It leaves every file executable, including.envfiles and keys. The usual approach is 755 for directories only and 644 for files, which is done withfind . -type d -exec chmod 755 {} +andfind . -type f -exec chmod 644 {} +.- SSH keys with open permissions.
sshrefuses to use a private key others can read. It has to be600. - Confusing permissions with ownership.
chmodchanges what can be done;chownchanges who owns it. Many problems that look like permissions are solved by the second one.
Frequently asked questions
What does chmod 755 mean?
Each digit is a group of users and each number is the sum of the permissions granted to it: read is 4, write is 2 and execute is 1. The first 7 is the owner (4+2+1, everything), and the two 5s are the group and everyone else (4+1, read and execute, but not write). In ls notation it reads as `rwxr-xr-x`. It is the usual value for directories and for scripts that need to be runnable.
What is the difference between 755 and 644?
The execute bit. 644 (`rw-r--r--`) gives read and write to the owner and read-only to everyone else, with execute for nobody: that is right for ordinary files such as an `.html`, a `.php` or an image. 755 adds the execute permission, which on a file means being able to run it as a program and on a directory means being able to enter it. The practical rule on a web server is 644 for files and 755 for directories.
Why does my directory return a 403 if it has read permission?
Because on a directory `x` does not mean execute, it means being able to traverse it. A directory with `r` but no `x` lets you list the names inside but not open any of those files, so the server cannot serve them. You need `x` on the directory and on every parent directory in the path. It is the most common cause of a 403 when permissions "look" right.
Why should I never use chmod 777?
Because it grants write access to any user on the system, and combined with the execute permission it means somebody can replace a file's contents and get them executed. On shared hosting that is a direct compromise path. When something "only works with 777", the real problem is almost always that the file belongs to the wrong user: the fix is `chown` to the web server user, not opening the permissions.
What are setuid, setgid and the sticky bit?
They are three extra bits occupying a fourth digit in front of the octal. setuid (4) makes a program run as its owner rather than as whoever launched it, and it is a classic privilege-escalation path if set without reason. setgid (2) on a directory makes everything created inside inherit its group, very useful on shared folders. The sticky bit (1) on a shared directory stops one user deleting another's files: it is what `/tmp` carries, which is `1777`. In `ls` these bits are displayed on top of the `x`, as an `s` or a `t`.
How is umask calculated?
umask is not subtracted from permissions, it is applied as a mask that removes them: the result is `base AND NOT umask`. The base is not the same for everything: the system asks for 666 for new files and 777 for directories, and never grants the execute bit to a file on its own. That is why with the most common umask, 022, a file is created as 644 and a directory as 755. Subtracting happens to work for round cases and breaks as soon as the umask has bits the base did not have: with umask 013 a file is created as 664, not 653.
Reviews & ratings
No reviews yet. Be the first to leave one!
Related guides
Blog tutorials where this tool comes in handy.
Related tools
Others from the catalogue that pair well with this one.