What is the Difference Between Chown and Chmod in Linux?

When working with files on a Linux system, you'll inevitably run into mysterious "Permission Denied" errors. Nine times out of ten, the solution comes down to two essential tools: chown and chmod.

This guide breaks down exactly what they do, how they're different, and—most importantly—how to use them to fix real problems like file access, ownership conflicts, and app deployment issues.

🧭 chmod vs. chown: At a Glance

They sound similar, but they solve very different problems.

What is Chown?

The chown command changes ownership—that is, who a file belongs to. Every file in Linux has both:

• A user owner
• A group owner

By default, files are owned by the user who created them.

Example

chown alice:dev-team report.txt

When you run this command, the ownership of the file report.txt is changed:

• User owner becomes alice
• Group owner becomes dev-team

If you want to change the ownership of a directory and all its contents, you can use the -R flag:

sudo chown -R www-data:www-data /var/www/html

This is common when setting up web servers like Apache or Nginx, where the web server user (www-data) needs access to website files.

Use chown when:

• A file is owned by root, but another user or process needs to access it
• You're setting up collaborative file editing using groups
• You're scripting deployments and need consistent ownership

What is chmod?

The chmod command changes what kind of access users and groups have over a file or directory. In Linux, every file has permission bits set for three categories:

• User (u) — The file’s owner
• Group (g) — The file’s group
• Others (o) — Everyone else

Each of these can be granted:

• Read (r) – view contents
• Write (w) – modify contents
• Execute (x) – run the file (if applicable)

Example

chmod u+x script.sh

User can now execute the script.

You can also use numeric notation:

chmod 755 script.sh

This breaks down as:

• 7 = read (4) + write (2) + execute (1) → for user
• 5 = read (4) + execute (1) → for group
• 5 = read (4) + execute (1) → for others

Use chmod when:

• A script isn’t running because it’s “not executable”
• You want to make a file read-only
• You’re securing a config file from accidental changes

Can Changing Ownership Grant Permissions?

Yes. Changing ownership with chown can allow a user to access a file—even without changing the file's permission bits.

Linux checks file access in this order:

1. Is the user the owner? → Use user permission bits
2. Is the user in the group? → Use group bits
3. Otherwise → Use others bits

Example

# File owned by root
ls -l notes.txt # This shows the file owner and group
-rw------- 1 root root 0 Jun 23 10:00 notes.txt

# Bob can't read this file.

sudo chown bob notes.txt

# Now:
-rw------- 1 bob root 0 notes.txt

Even though the permissions are still 600, Bob can now read and write, because he's the owner—and the user bits say rw-.

This is often used in automation, scripting, or transferring project ownership.

Warning

Don't casually chown system files. Ownership affects security boundaries. Use it with purpose.

Common Pitfalls and Pro Tips

1. chmod doesn’t give access if you’re not the owner You may be adding +x, but it won’t matter unless you own the file or belong to the right group.
2. Avoid chmod 777 It gives everyone full control. It's fine in a throwaway dev box, but in production, it’s a red flag
3. Use groups to scale access Instead of adding users one by one, create a group and assign ownership via chown :groupname:

sudo groupadd writers
sudo usermod -aG writers alice
sudo chown :writers doc.md
chmod 664 doc.md

Now anyone in writers can edit the file.

Conclusion

In Linux, understanding chmod and chown isn't just about fixing permission errors—it's about controlling your development environment with precision.

• Use chmod to control access.
• Use chown to control ownership—and gain access if needed.
• Respect the file system hierarchy and avoid lazy fixes like chmod 777.

Next time Linux pushes back, push smarter. You'll spend less time Googling errors and more time building great software.