chmod Permissions Cheat Sheet: 644, 755, 777 Explained (2026)

How Linux File Permissions Work

Every file and directory on a Linux system has three permission sets:

• Owner (u): The user who owns the file
• Group (g): The group assigned to the file
• Others (o): Everyone else

Each permission set has three bits: read (r=4), write (w=2), and execute (x=1). The octal (numeric) chmod value is the sum of these bits for each set.

# Read permission bits:
# r = 4, w = 2, x = 1
# rw- = 4+2+0 = 6
# rwx = 4+2+1 = 7
# r-- = 4+0+0 = 4
# r-x = 4+0+1 = 5

# So chmod 644 means:
# Owner: rw- (6) | Group: r-- (4) | Others: r-- (4)

ls -la somefile
# -rw-r--r-- 1 ubuntu ubuntu 2048 Mar 26 10:00 somefile
#  ^^^        ^                                    owner can rw
#     ^^^                                          group can r
#        ^^^                                       others can r

The execute bit on a directory has a different meaning: it grants the ability to traverse (enter) the directory. Without execute permission on a directory, you cannot cd into it or access files inside it, even if you have read permission on those files.

Quick Reference: Common Permission Values

Value  Symbolic     Who can do what
-----  -----------  ----------------------------------------
400    r--------    Owner read-only (e.g. .pem key backup)
444    r--r--r--    Read-only for everyone
600    rw-------    Owner read+write, nobody else (SSH keys, .env files)
644    rw-r--r--    Owner read+write, group/others read (standard files)
660    rw-rw----    Owner+group read+write, others nothing
664    rw-rw-r--    Owner+group read+write, others read
700    rwx------    Owner full access, nobody else (private dirs)
711    rwx--x--x    Others can traverse but not list (CGI dirs)
755    rwxr-xr-x    Owner full, group/others read+execute (web dirs, scripts)
775    rwxrwxr-x    Owner+group full, others read+execute (shared dirs)
777    rwxrwxrwx    Everyone full access (NEVER in production)

chmod 644 - Standard Files

chmod 644 is the standard permission for regular files. The owner can read and write; everyone else can only read.

chmod 644 index.php
chmod 644 config.yml
chmod 644 README.md

# Verify
ls -la index.php
# -rw-r--r-- 1 www-data www-data 4096 Mar 26 10:00 index.php

Use for: Web files (PHP, HTML, CSS, JS), configuration files, log files, any file that needs to be readable by processes but not writable by them.

Do not use for: Scripts that need to be executed (use 755), sensitive credentials (use 600), or SSH keys (use 600).

chmod 755 - Directories and Executable Scripts

chmod 755 is the standard permission for directories and executable scripts. The owner has full access; group and others can read and traverse (execute on directories means enter).

chmod 755 /var/www/html
chmod 755 deploy.sh
chmod 755 /usr/local/bin/myscript

# Set on all directories recursively
find /var/www/html -type d -exec chmod 755 {} \;

# Verify
ls -la deploy.sh
# -rwxr-xr-x 1 ubuntu ubuntu 512 Mar 26 10:00 deploy.sh

Use for: Web root directories, script files that need to be executed, application directories, /usr/local/bin/ scripts.

The most common web server setup: directories at 755, files at 644. This allows the web server to traverse and read, but not write to your web root.

chmod 700 - Private Directories

chmod 700 gives the owner full access and blocks everyone else completely - they cannot even list the contents or enter the directory.

chmod 700 ~/.ssh
chmod 700 /root
chmod 700 /home/user/private

ls -la ~/.ssh
# drwx------ 2 ubuntu ubuntu 4096 Mar 26 10:00 .ssh

Use for: The ~/.ssh directory (SSH will refuse to work if this is group or world readable), private key storage directories, backup directories with sensitive data, root home directory.

SSH has strict requirements: if ~/.ssh is not 700 or ~/.ssh/authorized_keys is not 600, SSH will refuse to authenticate and you will see WARNING: UNPROTECTED PRIVATE KEY FILE!.

chmod 600 - Private Files

chmod 600 allows only the owner to read and write. No one else has any access.

chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/authorized_keys
chmod 600 .env
chmod 600 /etc/ssl/private/server.key

ls -la ~/.ssh/id_rsa
# -rw------- 1 ubuntu ubuntu 1679 Mar 26 10:00 id_rsa

Use for: SSH private keys (required by SSH), .env files containing secrets, private TLS/SSL keys, database password files, any file that must not be readable by group members or other users.

The most common SSH connection failure after a fresh server setup or key copy is wrong permissions on ~/.ssh (must be 700) and ~/.ssh/authorized_keys (must be 600). Run chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys if SSH authentication is failing.

chmod 775 - Shared Team Directories

chmod 775 is used for directories shared within a team. Both the owner and the group can read, write, and traverse. Others can only read and traverse.

chmod 775 /var/www/shared-uploads
chown -R www-data:developers /var/www/shared-uploads
chmod 775 /var/www/shared-uploads

# Now both the www-data web server and the developers group
# can write to this directory

Use for: Upload directories shared between a web server process and deployment scripts, shared project directories where a team needs write access, log directories written by multiple processes in the same group.

chmod 777 - Never in Production

chmod 777 gives read, write, and execute access to absolutely everyone. On a multi-user system or a server connected to the internet, this is a serious security risk.

# DO NOT do this:
chmod 777 /var/www/html
chmod 777 uploads/

# If a web application has a file upload vulnerability and your
# uploads directory is 777, an attacker can write and execute
# PHP webshells directly.

The only legitimate use for 777 is temporary debugging on a local development machine when you need to quickly rule out a permission issue. Always revert it immediately. In production, use 755 for directories and set the appropriate owner/group instead of broadening permissions.

The scenario that lands servers in breach reports: an upload directory at 777 combined with an unrestricted file upload. The attacker uploads a PHP file, navigates to it in a browser, and has a web shell with the web server's process permissions. This has been the attack vector in countless real breaches.

Symbolic Notation

Octal numbers are concise but not self-explanatory. Symbolic notation lets you add or remove specific bits without needing to calculate the full value:

# Add execute permission for owner
chmod u+x script.sh

# Remove write permission for group and others
chmod go-w important.conf

# Set exact permissions symbolically
chmod u=rw,g=r,o=r file.txt   # same as 644
chmod u=rwx,g=rx,o=rx dir/    # same as 755

# Add sticky bit (useful on shared directories)
chmod +t /tmp/shared/          # same as chmod 1777

# Set permissions on owner only, no change to group/others
chmod u=rwx file.sh

Symbolic notation is especially useful in scripts where you want to add or remove a single bit rather than set all permissions at once. chmod +x script.sh is safer than chmod 755 script.sh when you do not know the current permissions and do not want to inadvertently grant or revoke group/other access.

Recursive chmod

The -R flag applies permissions recursively to all files and subdirectories. Use it carefully - applying the same permission to both files and directories is usually wrong:

# BAD: This makes all files executable (755 on files is almost never right)
chmod -R 755 /var/www/html

# GOOD: Directories at 755, files at 644
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

# GOOD: Make only .sh files executable
find /var/www/html -type f -name "*.sh" -exec chmod 755 {} \;

# Fix common Magento/WordPress web root in one command
find /var/www/html -type d -exec chmod 755 {} \; && \
find /var/www/html -type f -exec chmod 644 {} \;

Special Permission Bits

Setuid (4xxx)

When set on an executable, setuid causes it to run with the file owner's privileges, not the calling user's. This is how passwd can write to /etc/shadow even when called by a regular user:

chmod 4755 /usr/bin/myapp   # setuid + 755
# or: chmod u+s myapp
ls -la /usr/bin/passwd
# -rwsr-xr-x 1 root root ... /usr/bin/passwd
#    ^  's' indicates setuid is set

Setuid on shell scripts is ignored by the Linux kernel for security reasons. Only use setuid on compiled binaries when absolutely necessary, as it is a significant security risk.

Setgid (2xxx)

On a directory, setgid causes new files created inside to inherit the directory's group rather than the creating user's primary group. Useful for shared project directories:

chmod 2775 /var/www/project
# New files created here will belong to the www-data group
# regardless of which user creates them

Sticky Bit (1xxx)

On a directory, the sticky bit prevents users from deleting files they do not own, even if they have write permission on the directory. This is set on /tmp by default:

chmod 1777 /tmp   # world-writable but users can't delete others' files
ls -la / | grep tmp
# drwxrwxrwt  1 root root ... tmp
#          ^  't' indicates sticky bit

Real-World Permission Scenarios

Web server (Nginx/Apache + PHP-FPM)

# Web root owned by deploy user, readable by www-data
chown -R deploy:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

# Upload directory writable by web server
chown -R www-data:www-data /var/www/html/uploads
chmod 755 /var/www/html/uploads

SSH keys

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/config

.env and secrets files

chmod 600 .env
chmod 600 /etc/myapp/secrets.conf
# These files should also never be committed to git - use .gitignore

Frequently Asked Questions

What is the difference between chmod 644 and 664?

In 644, group has read-only access. In 664, group has read and write access. Use 644 for most web files where the group does not need to write. Use 664 when a deployment process running as a different user in the same group needs to overwrite files.

Why does chmod 777 cause security problems?

World-writable (w for others) means any process running as any user on the system can modify or delete that file. On a web server, this includes the web server process itself. If an attacker finds a code execution vulnerability, they can write malicious files to any 777 location and execute them via the web server.

How do I find files with insecure permissions on my server?

# Find world-writable files (potential security risk)
find /var/www -type f -perm -o+w

# Find world-writable directories
find /var/www -type d -perm -o+w

# Find setuid/setgid files (review each one)
find / -type f \( -perm -4000 -o -perm -2000 \) 2>/dev/null

What permissions should a .env file have?

A .env file containing application secrets should be 600 (owner read+write only). The application process must run as the same user that owns the file, or the file must be made readable to the application's group with 640. Never commit .env to version control - add it to .gitignore.

Does chmod affect the contents of a directory?

No. chmod 755 /var/www/html changes the directory's own permissions but does not affect the files inside. To change permissions recursively, use find ... -exec chmod or chmod -R. As shown above, always use find with separate rules for files (-type f) and directories (-type d) to avoid making all files executable.

The Bottom Line

The rule of least privilege applies directly to file permissions: grant only what is required. Directories need 755 or 700. Regular files need 644 or 600. Sensitive files (keys, secrets) need 600. World-writable (777) is almost never correct on a production server.

If you are auditing a server and find find /var/www -perm -o+w returning results, you have misconfigured permissions that represent real attack surface. Fix them before an attacker exploits them.

Use our Chmod Calculator to convert between numeric and symbolic notation, and explore our full tools collection for more DevOps utilities.