The Owner / Group / Other Permission Model

How Ownership Is Determined

Reading Permission Output

Octal vs Symbolic Notation: A Complete Comparison

Octal (Numeric) Notation

Symbolic Notation

When to Use Which?

Common Permission Patterns

755 — Standard for Executables and Directories

644 — Standard for Regular Files

600 — Private Files

400 — Read-Only Private Files

700 — Private Directories

750 — Group-Shared Directories

The chmod Command in Depth

Octal Mode

Symbolic Mode

Useful chmod Flags

Directory vs File Permissions

Special Permissions: Setuid, Setgid, and Sticky Bit

Setuid (4000) — Run as File Owner

Setgid (2000) — Run as File Group or Inherit Group

Sticky Bit (1000) — Restrict Deletion

Combining Special Permissions

Step-by-Step Tutorial: Using the DevToolkit Chmod Calculator

Security Best Practices: The Principle of Least Privilege

For Web Applications

For SSH

For Application Secrets

Common Mistakes and Troubleshooting

Mistake 1: chmod 777 Everything

Mistake 2: Recursive chmod on Mixed Content

Mistake 3: Forgetting Group Permissions

Mistake 4: Ignoring umask

Mistake 5: Not Using Groups Effectively

Troubleshooting "Permission Denied" Errors

umask: Controlling Default Permissions

Frequently Asked Questions

What does chmod 755 mean?

What is the difference between chmod 644 and 755?

Why is chmod 777 dangerous?

How do I make a file executable in Linux?

What permissions should .env files have?

How do I check current file permissions?

What is the difference between chmod and chown?

Can I undo a chmod command?

Conclusion File permissions are one of the first things that trip up developers on Linux and macOS. You get a "Permission denied" error, frantically Google "chmod 777", fix it, and move on — without really understanding what happened. This guide gives you a practical understanding of Unix permissions that will save you from both "Permission denied" errors and accidental security holes. Whether you are deploying web applications, managing SSH keys, or scripting server automation, having chmod permissions explained clearly will make you a more effective developer. Every file and directory on a Unix system has three sets of permissions for three classes of users: Each class can have three permissions: This three-by-three model creates a total of nine permission bits. Understanding how these bits interact is the key to managing file security on any Unix-like operating system. When you create a file, the operating system automatically sets you as the owner. The file's group is typically set to your primary group (which you can check with the id command). You can change ownership with chown and group with chgrp: Only the root user (or a user with sudo) can change file ownership. Regular users can only change the group to another group they belong to. When you run ls -la, you see permissions like -rwxr-xr-x. Here's how to read it: Each position is either the permission letter or a dash. Dashes mean "not granted." The file type character at the beginning is not a permission — it tells you what kind of filesystem entry you are looking at: There are two ways to express Unix file permissions: octal (numeric) and symbolic. Both are used with the chmod command, and each has advantages depending on the situation. The octal system represents each permission set as a single digit from 0 to 7. Each permission has a numeric value: So -rwxr-xr-x = 755. Three digits: owner, group, others. Here is the full reference table for a single digit: Symbolic notation uses letters and operators to modify permissions. It is more flexible when you want to change specific bits without affecting others: The user classes are: Use octal notation when you want to set all permissions at once and know exactly what the result should be. It is concise and unambiguous — chmod 644 file always produces the same result regardless of the file's current permissions. Use symbolic notation when you want to modify one specific permission without touching the rest. For example, chmod +x script.sh adds execute without changing any read or write bits. Use our Chmod Calculator to convert between octal, symbolic, and see the chmod command ready to copy. If you are working with number conversions in other contexts, our Number Base Converter can help with octal-to-binary and other base conversions. Here is a comprehensive reference table of the most common chmod permission patterns, what they mean, and when to use them: Owner can read, write, and execute. Everyone else can read and execute but not modify. This is the default for directories and executable scripts. Owner can read and write. Everyone else can only read. This is the default for most files. Only the owner can read and write. No access for anyone else. Use this for sensitive files like environment variables, database credentials, and private keys. If you are generating credentials, our Password Generator can create strong, random passwords. Owner can only read. SSH actually requires this — it refuses to use private keys with more permissive settings. If you get "Permissions 0644 for '~/.ssh/id_rsa' are too open", this is the fix. Only the owner can access the directory at all. Others can't even list its contents. Owner has full access, group members can read and enter the directory, and others have no access at all. This is ideal for team projects on shared servers. Symbolic mode lets you add or remove specific permissions without changing others: The same permission bits mean different things for files and directories: A common gotcha: a directory needs execute permission for users to access files inside it, even if those files have read permission. Without x on the directory, users can't reach the files. This is why directories almost always have execute permission (755 or 700) while regular files do not (644 or 600). Another subtlety: having write permission on a directory means you can delete any file in that directory, even files you do not own and cannot read. This is why the sticky bit (covered below) exists. Beyond the basic nine rwx bits, Unix has three special permission bits that control advanced behavior. These are represented by an optional fourth digit prepended to the octal notation. When the setuid bit is set on an executable file, the program runs with the permissions of the file's owner, not the user executing it. This is how the passwd command works — it is owned by root and has setuid set, which allows regular users to modify the /etc/shadow file that only root can write to. Notice the s in the owner's execute position. A lowercase s means both setuid and execute are set. An uppercase S means setuid is set but execute is not (which is usually a misconfiguration). Security warning: Setuid programs are a common attack vector. Never set setuid on scripts, and audit any setuid binaries on your system regularly. On executable files, setgid works like setuid but for the group — the program runs with the file's group permissions. On directories, setgid has a different and very useful behavior: new files and subdirectories created inside inherit the directory's group instead of the creating user's primary group. This is invaluable for team collaboration. Without setgid, files created by different users would belong to each user's primary group, making shared access unpredictable. The sticky bit on a directory prevents users from deleting files they do not own. Without it, anyone with write permission on the directory can delete any file inside it. The classic example is /tmp: The t at the end indicates the sticky bit. With this set, anyone can create files in /tmp, but only the file's owner (or root) can delete them. This prevents users from deleting each other's temporary files. Special permissions are added as a leading digit in octal notation: Use our Chmod Calculator to experiment with these special permission bits visually. If calculating octal values in your head feels error-prone, the DevToolkit Chmod Calculator makes it visual and instant. Here is how to use it: This is especially useful when you are configuring server deployments, writing CI/CD scripts, or setting up cron jobs that need specific file permissions. If you are building deployment scripts, you might also find our Regex Tester helpful for parsing log files and our JSON Formatter useful for reading configuration files. The golden rule of file permissions is the principle of least privilege: grant only the minimum permissions needed for a file or directory to function correctly. Here are concrete guidelines: To generate secure credentials for these files, use our Password Generator. For encoding sensitive data in configuration, our Base64 Encoder and Hash Generator can be useful. If you are working with JWT tokens, the JWT Decoder helps verify token contents without exposing secrets. chmod 777 gives everyone full access. This is a security risk and usually means you don't understand what permission is actually needed. Instead: Running chmod -R 755 . gives everything execute permission — including text files, images, and configs that should never be executable. Instead, set files and directories separately: On shared servers, group permissions matter. If multiple users need to edit files in a shared directory, set the group appropriately: The umask controls the default permissions for newly created files. A umask of 022 means new files get 644 and new directories get 755. A umask of 077 means new files get 600 and directories get 700. If your files always seem to have the wrong permissions, check your umask: The umask is subtracted from the maximum permissions (666 for files, 777 for directories). So with a umask of 027, new files get 640 and new directories get 750. Instead of loosening permissions with chmod 777, add users to appropriate groups and use group permissions: When you encounter "Permission denied", follow this diagnostic checklist: While chmod changes existing permissions, umask controls what permissions new files and directories receive. Understanding umask prevents you from having to chmod every new file. The umask value is a mask that is subtracted from the maximum permissions. Files have a maximum of 666 (no execute by default) and directories have a maximum of 777: Set your umask in ~/.bashrc or ~/.profile for persistent configuration. For servers handling sensitive data, a umask of 077 is a good baseline. chmod 755 sets the file to be readable, writable, and executable by the owner, and readable and executable (but not writable) by the group and others. In symbolic notation, this is rwxr-xr-x. It is the standard permission for executable scripts and directories. The difference is the execute bit. 644 (rw-r--r--) does not grant execute permission to anyone — use this for regular files like HTML, CSS, images, and config files. 755 (rwxr-xr-x) grants execute permission — use this for scripts, binaries, and directories (which need execute for users to enter them). chmod 777 grants read, write, and execute permissions to every user on the system. This means any user or process can modify or delete the file. On a web server, this could allow an attacker to inject malicious code. Always use the minimum permissions required. Use chmod +x filename to add execute permission for all users, or chmod u+x filename to add it only for the owner. For scripts, you also need a shebang line (e.g., #!/bin/bash) at the top of the file. Environment files containing secrets (API keys, database passwords, etc.) should have 600 permissions — only the owner can read and write. Never commit .env files to version control either; add them to your .gitignore. Use ls -la filename to see permissions in symbolic format, or stat filename for more detailed information including the octal representation. You can also use our Chmod Calculator to decode octal values into human-readable format. chmod changes what actions (read, write, execute) are allowed. chown changes who owns the file. Often you need both — for example, setting the correct owner and the correct permissions for a web server to access files properly. There is no built-in undo for chmod. If you accidentally change permissions and do not remember the original values, check your backup or use chmod --reference=similar_file broken_file to copy permissions from a known-good file. This is why it is always a good idea to check permissions with ls -la before changing them. Working with Unix systems involves more than just file permissions. Here are other DevToolkit tools that complement your workflow: File permissions are simple once you understand the model: three user classes, three permission types, three digits. With the addition of special permissions (setuid, setgid, sticky bit), umask defaults, and group management, you have a complete toolkit for securing files on any Unix-like system. Remember the essentials: use 644 for regular files, 755 for directories and scripts, 600 for sensitive files, and never use 777 unless you genuinely want every user on the system to have full access. When in doubt, follow the principle of least privilege — start restrictive and loosen only as needed. Need to calculate permissions quickly? Our Chmod Calculator lets you toggle permissions visually and copies the chmod command to your clipboard — no mental math required. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse