Learn the key differences between chmod and chown in Linux, two commands that control different aspects of file security. We'll explain when to use each one and how they work together to protect your system.
Publish date: 12/17/2025
If you've spent any time managing a Linux server, you've probably run into permission errors. Maybe a script won't execute, a web server can't read a config file, or a user can't access a directory they should be able to. These problems usually come down to two commands: chmod and chown.
While they both deal with file security, they serve completely different purposes. Understanding when to use each one (and how they work together) is one of those foundational skills that makes server management much smoother.
Here's the short version: chmod changes what users can do with a file, while chown changes who owns the file in the first place.
Think of it like a house. The owner (set by chown) has the keys and decides who gets access. The permissions (set by chmod) are like locks on different doors, controlling whether someone can enter, look around, or make changes.
Linux tracks three types of access for every file and directory:
Each of these categories can have read, write, and execute permissions. That's where chmod comes in.
The chmod command modifies file permissions. You can think of it as setting the rules for who can read, write, or execute a file.
There are two ways to use chmod: symbolic mode and numeric (octal) mode.
Symbolic mode uses letters to represent permissions:
r = readw = writex = executeYou combine these with:
u = user (owner)g = groupo = othersa = allFor example, to give the owner execute permission on a script:
chmod u+x script.sh
To remove write access for others:
chmod o-w myfile.txt
Numeric mode uses three digits, one for each category (owner, group, others). Each digit is the sum of:
So chmod 755 means:
This is commonly used for web directories. The owner can do everything, while the group and others can read and navigate but not modify files.
Another common permission is 644:
chmod 644 index.html
This gives the owner read and write access (4+2), while the group and others can only read (4).
You'll see chmod 600 for sensitive files like SSH keys, which only the owner should access:
chmod 600 ~/.ssh/id_rsa
While chmod controls permissions, chown changes file ownership. The syntax is straightforward:
chown username filename
You can also change the group at the same time:
chown username:groupname filename
Or just the group:
chown :groupname filename
Let's say you've installed a web application and the files are owned by root, but your web server runs as the www-data user. The server won't be able to read the files. You'd fix this with:
chown www-data:www-data /var/www/html -R
The -R flag applies the change recursively to all files and subdirectories.
Sometimes you only need to change the group. For example, if you want multiple users in the developers group to access a project:
chown :developers /home/projects/myapp -R
Use chown when you need to transfer ownership of files. This happens when:
Use chmod when you need to adjust what different users can do with files. Common scenarios include:
Often you'll need both. When deploying a web application, you might set ownership with chown to make sure the web server user owns the files, then use chmod to set appropriate read/write/execute permissions.
For instance, deploying a PHP application typically looks like this:
chown www-data:www-data /var/www/myapp -R
chmod 755 /var/www/myapp
chmod 644 /var/www/myapp/*.php
This gives ownership to the web server, allows it to navigate directories, and lets it read (but not modify) the PHP files.
Some permission sets come up again and again:
755 - Standard for directories and executable scripts. Owner can modify, everyone can read and execute.
644 - Standard for regular files. Owner can edit, everyone can read.
600 - Private files like SSH keys. Only the owner can access.
700 - Private directories. Only the owner can access.
775 - Shared directories where a group needs write access.
666 - Rarely used, but allows everyone to read and write (dangerous for most files).
You can check current permissions with ls -l:
ls -l myfile.txt
-rw-r--r-- 1 user group 1234 Dec 3 10:00 myfile.txt
The first column shows permissions (rw-r--r--), followed by the owner (user) and group (group).
Beyond basic read/write/execute, Linux has a few special permission bits worth knowing about.
When set on an executable, the program runs with the permissions of the file's owner rather than the user who launched it. This is represented by an s in the owner's execute position:
chmod u+s /usr/bin/someprogram
Or numerically as 4755. The leading 4 sets the setuid bit.
Similar to setuid but for groups. When set on a directory, new files created inside inherit the directory's group rather than the creator's default group:
chmod g+s /shared/project
Or 2755 numerically.
Usually applied to shared directories. When set, only the file owner can delete or rename files in that directory, even if others have write access. The /tmp directory uses this:
chmod +t /shared/uploads
Or 1755 numerically.
Bad permissions are one of the most common security issues on Linux servers. A few guidelines:
Never use 777 unless you absolutely have to (and you probably don't). This gives everyone full access, which is almost never appropriate.
Be careful with chown on system files. Changing ownership of critical system files can break your system or create security holes.
Use the principle of least privilege. Give users and processes only the minimum permissions they need to function.
Watch out for world-writable files. If you see w in the "others" column of ls -l, think twice about whether that's necessary.
Configuration files with passwords or API keys should be 600 or 640 at most, owned by the user that needs them.
When running web applications, separate the web server user from the file owner when possible. This limits damage if the application is compromised.
When something doesn't work, permission problems are often the culprit. Start by checking ownership and permissions:
ls -la /path/to/problem/file
If a script won't execute, make sure it has the execute bit set:
chmod +x script.sh
If a service can't read its config file, check both ownership and permissions:
chown service-user:service-user /etc/service/config
chmod 640 /etc/service/config
Parent directory permissions matter too. Even if a file has proper permissions, you can't access it if you don't have execute permission on the directories leading to it.
SELinux or AppArmor can also block access even when standard permissions look correct. Check system logs if you've verified permissions and still have issues.
While chmod 777 might seem like an easy fix for permission errors, it creates major security risks by giving all users full read, write, and execute access to your files. It's particularly dangerous on web servers where it could allow attackers to modify or execute files. Instead, identify exactly which user or group needs access and set minimum permissions like 755 for directories or 644 for files.
Only the file owner and root can modify permissions with chmod. Regular users can't change permissions on files they don't own, even if they have read or write access. If you need to modify permissions on files owned by another user, you'll need root access or ask the owner to make the changes.
SSH requires private keys to have strict permissions for security. If your key file is readable by other users, SSH refuses to use it. Fix this with chmod 600 ~/.ssh/id_rsa to restrict access to only the owner. This is a safety feature that prevents others from copying your private key.
Both syntaxes work identically in modern Linux systems. The colon (:) is the standard separator, while the dot (.) is an older notation that's still supported. However, the colon is recommended because usernames can contain dots, which could cause ambiguity with the dot syntax. Stick with chown user:group for clarity.
Yes, basic chmod and chown functionality works identically across all Linux distributions since they follow the POSIX standard. However, some distributions may have additional security layers like SELinux (on RHEL-based systems like AlmaLinux or Rocky Linux) or AppArmor (on Debian and Ubuntu) that can enforce additional access controls beyond standard file permissions.
Understanding chmod and chown is one of those skills that pays dividends every time you work with a Linux system. Whether you're deploying applications, troubleshooting access issues, or hardening security, knowing when to change ownership versus when to adjust permissions makes everything easier.
Start with conservative permissions and loosen them only when necessary. It's much better to deal with a "permission denied" error than to accidentally expose sensitive data or give malicious code an easy path to execution.
If you're looking for infrastructure to put these skills to work, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting that's perfect for any workload. We also offer IP transit, shared hosting, and a full range of IT services.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.