chmod Calculator Online: De complete Linux bestandsrechten gids

1. What Are Linux File Permissions?

Every file and directory on a Linux or Unix-like system carries a set of file permissions that control access. These permissions are stored as metadata alongside the file and are enforced by the kernel on every read, write, or execute operation. When you run ls -la, the leftmost column displays the permission string, for example -rwxr-xr--. Understanding this string is the first step to mastering Linux security.

The permission system has three fundamental access types. Read (r) allows a user to view the contents of a file or list the contents of a directory. Write (w) allows modifying a file or creating, deleting, and renaming entries inside a directory. Execute (x) allows running a file as a program (scripts, binaries) or entering a directory with the cd command. Without execute permission on a directory, you cannot access anything inside it, even if you have read permission.

The permission string from ls -l has 10 characters. The first character indicates the file type: - is a regular file, d is a directory, l is a symbolic link, c is a character device, b is a block device. The remaining nine characters are three groups of three bits each, representing owner, group, and others permissions.

-rwxr-xr--  2  alice  webteam  4096  Feb 27  deploy.sh
^└─ file type: - = regular file
 \rwx──────  owner (alice): read + write + execute
    \r-x───  group (webteam): read + execute
       \r--    others: read only

→ Try our free interactive chmod calculator now

2. The Three-Layer Model: Owner, Group, Others

Linux uses a three-layer access model. The owner (also called "user" or "u") is the account that created the file. The group ("g") is a named collection of users who share common access rights. Others ("o") — sometimes called "world" — refers to everyone else on the system who is not the owner and not in the file's group.

When the kernel checks permissions for an access request, it checks layers in order. If the requesting user is the file owner, the owner bits apply and no further checking occurs. If the user is a member of the file's group, the group bits apply. Otherwise, the others bits apply. This means the owner's permissions apply exclusively to the owner and do not cascade. A common gotcha: a file with permissions ---rwxrwx gives the owner no access while group and others have full access.

You can view a file's owner and group with ls -la — the third and fourth columns show the owner and group names respectively. Use stat filename for even more detail, including the octal representation of the permissions:

$ ls -la deploy.sh
-rwxr-xr--  1  alice  webteam  4096  deploy.sh

$ stat deploy.sh
  File: deploy.sh
  Size: 4096      Blocks: 8    IO Block: 4096  regular file
Device: 803h/2051d  Inode: 131073  Links: 1
Access: (0754/-rwxr-xr--)  Uid: ( 1001/   alice)   Gid: ( 1002/ webteam)

3. Numeric (Octal) vs Symbolic Notation

Linux permissions can be expressed in two ways: numeric (octal) and symbolic. Both represent the same nine bits, but they are useful in different contexts. The numeric form is faster to type and easier to reason about when setting all permissions at once. The symbolic form is better when you want to add or remove a single permission without affecting others.

In numeric mode, each of the three permission types is assigned a numeric value: Read = 4, Write = 2, Execute = 1. For each layer (owner, group, others), you add up the values of the permissions you want to grant, producing a digit from 0 to 7. Three such digits form the complete permission number. For example, chmod 755 means: owner 7 (4+2+1 = rwx), group 5 (4+0+1 = r-x), others 5 (4+0+1 = r-x).

Quick reference for the eight possible octal digits:

In symbolic mode, you specify who (u=owner, g=group, o=others, a=all), an operator (+=add, -=remove, ==set exactly), and the permissions (r, w, x). Multiple changes can be comma-separated. The key advantage of symbolic mode is that it does not touch bits you do not mention, making it safer for selective changes.

# Numeric mode — set all nine bits at once
chmod 755 script.sh    # rwxr-xr-x
chmod 644 index.html   # rw-r--r--
chmod 600 .env         # rw-------

# Symbolic mode — modify specific bits
chmod u+x script.sh    # add execute for owner
chmod go-w config.php  # remove write from group+others
chmod a+r readme.txt   # add read for everyone
chmod u=rwx,go=rx dir/ # set exactly: 755

4. Common Permission Values: 644, 755, 777, 700, 600

Certain permission values appear constantly in web development, DevOps, and system administration. Knowing them by heart makes you faster and safer. Here is a comprehensive reference table of the most important chmod values:

The three most important values to memorize are 644 (standard file), 755 (standard directory or executable), and 600 (sensitive secrets). Get these right and you will handle 90% of real-world situations correctly.

For web servers, the typical convention is directories at 755 and files at 644. This allows the web server process (often running as www-data or nginx) to traverse directories and read files while preventing unauthorized modifications. Configuration files that contain credentials should be 640 or 600.

5. Understanding setuid, setgid, and the Sticky Bit

Beyond the standard nine permission bits, Linux supports three special permission bits that modify how files and directories behave. These are represented as a leading fourth digit in the octal notation and appear as special characters in ls -l output. Misunderstanding them is a common source of security vulnerabilities.

setuid (SUID) — 4000

When the setuid bit is set on an executable file, the process runs with the file owner's effective user ID instead of the user who executes it. The classic example is /usr/bin/passwd: it needs root privileges to modify /etc/shadow, yet any user must be able to change their own password. In ls -l, SUID replaces the owner execute bit: -rwsr-xr-x. If the file has no execute permission for the owner, the s appears as uppercase S (-rwSr-xr-x), indicating the bit is set but ineffective. On directories, setuid is generally ignored on Linux (though respected on some BSDs).

setgid (SGID) — 2000

On an executable file, setgid causes the process to run with the file's group as the effective group ID. On a directory, setgid is far more commonly useful: new files and subdirectories created inside automatically inherit the directory's group, rather than the creator's primary group. This is the standard mechanism for shared team directories where all files must belong to the same group. In ls -l, the group execute bit changes to s (or S if execute is not set).

Sticky Bit — 1000

On a directory, the sticky bit restricts deletion: only the file's owner, the directory's owner, or root can delete or rename files within it, even if other users have write permission on the directory. The canonical example is /tmp (permissions 1777): every user can create files there, but no one can delete another user's files. In ls -l, the others execute bit shows as t (or T if execute is not set): drwxrwxrwt. On files, the sticky bit is ignored on modern Linux systems.

# Setting special bits (numeric: prefix with 4, 2, or 1)
chmod 4755 /usr/local/bin/myapp  # setuid: rwsr-xr-x
chmod 2775 /var/www/shared        # setgid: rwxrwsr-x
chmod 1777 /tmp/scratch           # sticky: rwxrwxrwt

# Symbolic alternatives
chmod u+s myapp   # set SUID
chmod g+s shared/ # set SGID on directory
chmod +t scratch/ # set sticky bit

# Check special bits with ls
ls -la /usr/bin/passwd
-rwsr-xr-x 1 root shadow 68208 /usr/bin/passwd
#   ^ s = setuid is set

6. chmod vs chown vs chgrp

Permission management in Linux involves three distinct commands that are often confused. Understanding the difference between them is essential for correct system administration.

chmod (change mode) modifies the permission bits of a file or directory. It changes who can read, write, or execute the file. It does not change the file's owner or group. Syntax: chmod [options] mode file...

chown (change owner) changes the owner and optionally the group of a file. Only root can change the owner of a file. Regular users can change the group to another group they belong to. Syntax: chown [options] owner[:group] file...

chgrp (change group) changes only the group of a file. It is equivalent to chown :group file but is more explicit when you only want to change the group. Syntax: chgrp [options] group file...

# chmod: change permissions
chmod 644 config.php
chmod u+x deploy.sh
chmod -R 755 public_html/

# chown: change owner
chown alice file.txt          # change owner to alice
chown alice:webteam file.txt  # change owner and group
chown -R www-data:www-data /var/www/html/

# chgrp: change group
chgrp webteam project.conf
chgrp -R developers /srv/app/

# Check result
ls -la file.txt
-rw-r--r-- 1 alice webteam 1024 Feb 27 file.txt

7. Viewing Permissions with ls -la

The ls -la command is the standard way to inspect file permissions. The -l flag enables long format and -a shows hidden files (those beginning with a dot). Each line contains the permission string, hard link count, owner name, group name, file size, modification timestamp, and filename.

Reading the permission string: the first character is the file type. The next three characters are the owner's permissions (read, write, execute). The following three are the group's permissions. The final three are others' permissions. A letter indicates the permission is granted; a dash indicates it is denied.

$ ls -la /var/www/html/
total 48
drwxr-xr-x  4  www-data  www-data  4096  Feb 27 .
drwxr-xr-x  8  root      root      4096  Feb 20 ..
-rw-r--r--  1  www-data  www-data  2048  Feb 27 index.html
-rw-r-----  1  www-data  www-data   512  Feb 25 config.php
drwxr-xr-x  2  www-data  www-data  4096  Feb 26 assets/
drwxrws---  2  www-data  webteam   4096  Feb 27 uploads/
-rwsr-xr-x  1  root      root      8192  Feb 10 setuid-tool

# Breakdown of -rw-r-----:
# - : regular file
# rw- : owner can read and write (6)
# r-- : group can only read (4)
# --- : others have no access (0)
# = chmod 640

The stat command gives even more detail, including the octal permission value directly, the inode number, and timestamps for access, modification, and change. This is useful for scripting and verification:

$ stat /var/www/html/config.php
  File: /var/www/html/config.php
  Size: 512
  Access: (0640/-rw-r-----)
  Uid: (33/www-data)  Gid: (33/www-data)

8. Recursive Permission Changes with chmod -R

The -R (recursive) flag applies permission changes to a directory and everything inside it. While convenient, it must be used carefully because it applies the same permission bits to both files and directories — which often have different requirements.

The problem with naive chmod -R 755: directories need execute permission (to be traversed), but regular files generally should not be executable. Setting 755 recursively makes every file executable, which is both unnecessary and a security concern.

The correct approach uses find with -type f and -type d to apply different permissions to files and directories separately:

# WRONG: makes all files executable too
chmod -R 755 /var/www/html/

# CORRECT: different permissions for files and directories
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

# Fix a deploy directory (more efficient with +)
find /var/www/html -type d -exec chmod u=rwx,go=rx {} +
find /var/www/html -type f -exec chmod u=rw,go=r {} +

# Preserve execute bit only for already-executable files
find /var/www/html -type f -perm /111 -exec chmod 755 {} +
find /var/www/html -type f ! -perm /111 -exec chmod 644 {} +

9. Permission Best Practices for Web Servers

Web server permissions are one of the most critical security configurations for any application deployment. Getting them wrong can lead to data breaches, defacements, or privilege escalation. Here is the authoritative reference for Apache and Nginx deployments.

Web root files and directories: The standard convention is 644 for files and 755 for directories. The web server process (www-data, nginx, or apache) needs read access to files and execute (traverse) access to directories. Never give the web server write access to the web root.

# Standard web server permissions
find /var/www/html -type d -exec chmod 755 {} +
find /var/www/html -type f -exec chmod 644 {} +

# Ownership: root owns files, web server can read
chown -R root:www-data /var/www/html/

# PHP/config files: even more restrictive
chmod 640 /var/www/html/config.php   # owner rw, group r
chmod 600 /var/www/html/.env         # owner rw only

Upload directories: If your application allows file uploads, the upload directory must be writable by the web server process. Grant group write permission and ensure the web server process is in the group:

# Upload directory: web server can write, but sticky for safety
chmod 2775 /var/www/html/uploads/   # setgid + owner:rwx group:rwx
chown root:www-data /var/www/html/uploads/

# Even more secure: completely separate upload directory
mkdir -p /srv/uploads
chown www-data:www-data /srv/uploads
chmod 700 /srv/uploads  # only www-data can access

SSH keys: SSH is extremely strict about key permissions. If permissions are too open, SSH refuses to use the key with "WARNING: UNPROTECTED PRIVATE KEY FILE!"

# SSH keys: exact permissions required
chmod 700 ~/.ssh/             # directory: owner only
chmod 600 ~/.ssh/id_ed25519   # private key: owner rw only
chmod 644 ~/.ssh/id_ed25519.pub  # public key: readable
chmod 600 ~/.ssh/authorized_keys  # authorized keys
chmod 644 ~/.ssh/known_hosts      # known hosts

Environment and secret files: Files containing API keys, database passwords, and other credentials must be restricted to the minimum necessary access:

# Secret files: owner read-write only
chmod 600 .env
chmod 600 database.yml
chmod 600 secrets.json
chmod 400 ssl-private.key  # SSL private key: read only

# Check for overly permissive files
find /var/www -name ".env" -perm /044
find / -name "*.pem" -perm /022 -type f

10. Troubleshooting: 403 Forbidden and Permission Denied

Permission errors are among the most common causes of application failures during deployment. The two most frequent errors are HTTP 403 Forbidden and shell "Permission denied" messages. Here is a systematic troubleshooting guide.

HTTP 403 Forbidden

A 403 error from a web server almost always indicates a permission problem. The web server process cannot read the requested file or traverse a parent directory. Check permissions on the file itself AND all parent directories in the path:

# Check the full path permissions
namei -l /var/www/html/app/config.php
f: /var/www/html/app/config.php
 drwxr-xr-x root     root     /
 drwxr-xr-x root     root     var
 drwxr-xr-x root     root     www
 drwxr-xr-x root     www-data html
 drwxr-x--- root     www-data app     <- missing execute for others!
 -rw-r--r-- www-data www-data config.php

# Fix the directory
chmod 755 /var/www/html/app/

# Also check if the web server user can read the file
sudo -u www-data stat /var/www/html/app/config.php

Permission Denied in Shell

Shell "Permission denied" errors occur when a user lacks the necessary permission bits. Diagnose with ls -la and compare against the current user:

# Check who you are
whoami
id

# Check file permissions and ownership
ls -la problematic-file

# Check directory execute permission
ls -la /path/to/directory/

# Common fixes
chmod +x script.sh          # forgot to make script executable
sudo chown $USER file.txt   # wrong owner
newgrp groupname            # join a group without re-login

# Check effective permissions (Linux 4.5+)
getfattr -n system.posix_acl_access file

11. File vs Directory Permissions: Key Differences

The same permission bits mean different things for files versus directories. This distinction trips up many developers, especially when setting recursive permissions.

For files: Read (r) allows viewing the file contents. Write (w) allows modifying or replacing the file contents. Execute (x) allows running the file as a program. The permissions apply directly to the file data.

For directories: Read (r) allows listing the directory contents with ls. Write (w) allows creating, deleting, and renaming entries inside the directory — not modifying files within it. Execute (x) allows entering the directory with cd and accessing files inside it by name. Without execute, you cannot access anything inside the directory even if you know the filenames.

This distinction has important security implications. A directory with write permission allows deleting any file inside it regardless of the file's own permissions. This is why the sticky bit (1000) on /tmp is critical — it prevents users from deleting each other's files despite having write access to the directory.

12. ACL (Access Control Lists) for Advanced Permissions

The classic Unix permission model (owner/group/others) only allows one owner and one group per file. For scenarios requiring access by multiple specific users or groups, this model becomes limiting. Access Control Lists (ACLs) extend the permission system to allow per-user and per-group rules.

ACLs are supported on most modern Linux filesystems (ext4, xfs, btrfs) and can be managed with the getfacl and setfacl commands. You must ensure the filesystem is mounted with ACL support (usually enabled by default on modern distros).

# View ACLs
getfacl /var/www/project/
# file: /var/www/project/
# owner: alice
# group: webteam
user::rwx
group::r-x
other::r-x

# Grant additional user (bob) read access
setfacl -m u:bob:r-- /var/www/project/secret.conf

# Grant a specific group write access
setfacl -m g:deployteam:rw /var/www/project/config/

# Apply ACL recursively
setfacl -R -m u:bob:rx /var/www/project/

# Set default ACL for new files in directory
setfacl -d -m u:bob:rx /var/www/project/

# Remove ACL entry
setfacl -x u:bob /var/www/project/secret.conf

# Remove all ACLs
setfacl -b /var/www/project/secret.conf

When a file has ACLs, ls -l shows a + after the permission string: -rw-r--r--+. The effective permission for a user is determined by combining the base permissions with any applicable ACL entries. Mask entries in ACLs can further limit effective permissions.

13. Frequently Asked Questions

Conclusion

Understanding Linux file permissions is a foundational skill for every developer working with servers, containers, or CI/CD pipelines. The three-layer model (owner, group, others), the numeric encoding (read=4, write=2, execute=1), and the key values (644, 755, 600) cover the vast majority of real-world scenarios. For complex access patterns, ACLs provide the flexibility of per-user and per-group rules. Use our chmod calculator to generate the exact command you need without manually computing octal sums.

Calculate any chmod value instantly with our free online chmod calculator.