Common Permissions

How to Use

1. Toggle the checkboxes to set read, write, and execute permissions for Owner, Group, and Others.
2. Or type a 3-digit numeric value (e.g., 755) directly.
3. The symbolic notation and chmod command update in real time.
4. Click Copy Command to copy the full chmod command.

Permission Reference

Frequently Asked Questions

What does chmod 755 mean?

755 means the owner can read, write, and execute (7), while the group and others can read and execute but not write (5). This is the most common permission for directories and scripts.

What's the difference between 644 and 755?

644 (rw-r--r--) allows the owner to read/write and everyone else to read only · typical for files. 755 (rwxr-xr-x) adds execute permission · typical for directories and scripts.

Does this work for directories too?

Yes. The numeric permissions work the same way. For directories, "execute" means the ability to enter the directory and access its contents.

The Unix permission model in 9 bits

Every file and directory on a Unix-like system carries a "mode", a small integer that records who can do what. The model is essentially unchanged since Sixth Edition Unix (May 1975), with the earliest chmod manual entries appearing in Version 1 Unix (November 1971). It encodes nine permission bits arranged as three triples of read / write / execute, one triple each for the file's owner, its group, and everyone else:

Owner    Group    Others
r w x    r w x    r w x
4 2 1    4 2 1    4 2 1

Each three-bit group is exactly one octal digit because three bits encode 2³ = 8 distinct values (0–7). The weights 4, 2, 1 are 2², 2¹, 2⁰. Adding any combination of read (4) + write (2) + execute (1) produces the eight possible per-class digits without collision, that's the entire octal-to-symbolic mapping. chmod 755 therefore means rwx (4+2+1=7) for the owner, r-x (4+1=5) for the group, and r-x for everyone else.

The 10-character string you see in ls -l is the same data plus one extra column up front for the file type: - for a regular file, d for a directory, l for a symlink, c for a character device, b for a block device, p for a named pipe, s for a socket. The remaining nine characters are the permission triples.

Symbolic notation: chmod u+x file

Octal modes overwrite all nine bits at once. Symbolic modes are non-destructive, they only flip the bits you name. The grammar is who + op + perm:

• who: u user/owner, g group, o others, a all (= ugo).
• op: + adds, - removes, = sets exactly (and clears the others).
• perm: r, w, x, plus the special letters X (execute only if the target is a directory or already executable on at least one class), s (setuid / setgid), t (sticky / restricted-deletion). You can also copy from another class with u, g, o: e.g., g=u sets group permissions identical to owner.

Useful examples:

• chmod u+x script.sh: add execute for the owner only.
• chmod g-w shared.log: remove write for the group.
• chmod a=rw note.txt: set everyone to read/write, clear execute for all.
• chmod o= secret.key: clear all bits for "others".
• chmod -R u+rwX,go+rX /var/www: recursively grant owner full access and others read; the capital X adds execute only on directories or files that already have it on some class, avoiding accidentally making every text file executable.

Numeric modes are explicit and idempotent (chmod 755 always means the same nine bits). Symbolic modes are surgical (chmod g+w only flips one bit). Production scripts tend to favour numeric for clarity in audit logs; operators typing at the shell tend to favour symbolic for incremental tweaks.

Common modes and what they're for

Mode	Symbolic	Typical use
755	rwxr-xr-x	Public executables and standard directories, /usr/bin/*, web docroots, Git working trees
644	rw-r--r--	Standard regular files, config, source code, documents
700	rwx------	Private directory, ~/.ssh, personal docs nobody else should see
600	rw-------	Private file, ~/.ssh/id_rsa, ~/.gnupg/*, password files
444	r--r--r--	Read-only for everyone, fixed reference data, Cargo registry indexes
750	rwxr-x---	Owner full, group read/traverse, others nothing, group-shared service directory
777	rwxrwxrwx	Almost always wrong. See below.

Why chmod 777 is almost always wrong

Setting a file to 777 makes it world-readable, world-writable and world-executable. Any user on the machine (including unprivileged service accounts and any process that ever gets compromised) can read the file's contents, modify it, and run it. The standard tutorial advice "just chmod 777 until it works" is a security antipattern that has been responsible for countless real breaches: world-writable configuration files that get tampered with, world-writable web directories that become defacement vectors, world-writable log files that allow log forgery, world-executable directories that allow arbitrary code execution.

If a permissions error is blocking you, the right fix is almost always to change the file's owner (with chown) or its group (with chgrp) so the user that needs access actually owns or co-owns the file, not to remove access controls for everyone.

Special bits: setuid, setgid, sticky

A fourth octal digit prepended to the mode unlocks three special bits, all relics of the original Unix design:

• 4xxx, setuid (set user ID). When set on an executable, the program runs with the owner's privileges instead of the invoker's. The classic example is passwd: every user can run it, but only because it's setuid-root can it write to /etc/shadow. Setuid is a major security surface, modern Linux increasingly replaces it with file capabilities (more granular permission bits via setcap), and many distros are progressively removing setuid bits.
• 2xxx, setgid (set group ID). On an executable, runs with the file's group; on a directory, files created inside inherit the directory's group rather than the creator's primary group, useful for shared project directories.
• 1xxx) sticky bit. On a directory, only the file owner (or root) can delete or rename files inside, regardless of write permission on the directory itself. The canonical use is /tmp: world-writable so any user can create files, but the sticky bit prevents users from deleting each other's files.

The ls -l display swaps the execute character to s, S, t or T when these bits are set (capital letters mean the bit is set but the underlying execute bit is not).

umask: the inverse of chmod

chmod sets permissions on existing files. umask determines the default permissions on files you create, by acting as a subtractive mask. The arithmetic: a new regular file would be 666 (rw-rw-rw-), a new directory 777, minus whatever's set in the umask. Common values:

• umask 022 (the default on most Linux distros), strips write from group and others. New files end up at 644, new directories at 755.
• umask 002 (default in some shared-development environments), strips write only from others. New files at 664, directories at 775. Useful when a development team wants to read and edit each other's files.
• umask 077 (common on private servers and security-conscious setups), strips all permissions for group and others. New files at 600, directories at 700.

Typing umask with no arguments shows the current value. Setting it in your shell init (~/.bashrc, ~/.zshrc) or in /etc/login.defs applies to the whole session.

Files vs directories, different meanings of x

The same r/w/x bits mean subtly different things on directories than on files:

• Read on a directory: list its contents. Without read, you can still access a known filename inside the directory if you have execute, but ls won't work.
• Write on a directory: create, delete, or rename entries inside. Note: this is independent of write permission on the files themselves. Write on the directory plus the sticky bit (1xxx) is what allows controlled multi-user shared directories like /tmp.
• Execute on a directory: traverse it (cd into it, access named entries inside). A directory without execute is effectively a dead end. Many subtle "permission denied" issues come from this distinction: you have read on a deep directory but not execute on one of its parents, so you can't reach it.

Recursive chmod and the find pattern

chmod -R 755 /var/www applies the same mode to every file and directory in the tree, which is almost always wrong because files and directories want different modes (e.g., 644 for files, 755 for directories). The correct idiom uses find:

find /var/www -type f -exec chmod 644 {} +
find /var/www -type d -exec chmod 755 {} +

Or, equivalently, using GNU chmod's capital X: chmod -R u=rwX,go=rX /var/www grants execute only on directories and on files that already had execute somewhere, exactly the result you usually want.

Symlinks, ACLs, and how Linux extends the model

Two refinements worth knowing:

• Symlinks have their own mode (always 777) but it's ignored. chmod follows the link and modifies the target by default. Use chmod -h on BSD or chmod --no-dereference on GNU to operate on the link itself, though there's rarely any reason to.
• POSIX ACLs (setfacl, getfacl) extend the basic model with per-user and per-group entries. A file can grant write to a specific user without touching the standard mode bits. ls -l shows a trailing + on files with ACLs. macOS, most Linux filesystems and the BSDs all support them; they're optional and many sysadmins prefer to stick with the simpler classic mode.
• Windows NTFS ACLs are richer still, per-user / per-group entries with explicit allow / deny bits and inheritable inheritance. The chmod model doesn't translate directly. Cygwin and WSL emulate it imperfectly on top of NTFS.

More questions

Why does my SSH key get rejected with "permissions are too open"?

Because the OpenSSH client refuses to use a private key that's group- or world-readable, on the assumption that anything other people can read shouldn't be a credential. The fix is chmod 600 ~/.ssh/id_rsa (and chmod 700 ~/.ssh on the directory itself). Same logic for ~/.gnupg/ and most other credential stores.

What's the difference between chmod and chown?

chmod changes the mode bits, what owner/group/others can do. chown changes who the owner is. Frequently you need both: a file that "the wrong user can't read" usually doesn't need its permissions opened up; it needs to be owned by the user that needs access. Try chown myuser:mygroup file first.

Should I use 666 for log files?

Almost never. World-writable log files allow any process (including a compromised service running as a low-privilege user) to forge log entries or wipe the log. The standard pattern is to make the log directory writable by a specific log group (adm on Debian, wheel on BSD, etc.) and add the relevant services to that group, or to use logrotate + a logging daemon (rsyslog, systemd-journald) that handles file ownership for you.

Does this calculator account for the special bits?

No, it covers the base nine permission bits (the standard 3-digit mode). For setuid (4xxx), setgid (2xxx) or sticky (1xxx) you'd prepend the leading digit manually. The vast majority of day-to-day chmod work uses 3-digit modes and never touches the special bits.

Does anything get sent to a server?

No. The toggle ↔ octal ↔ symbolic conversion is pure arithmetic, computed in your browser. The page works offline once it's loaded.

Related Tools