chmod vs chown vs sudo - When to Use Each in Linux

2025-01-11 Reading time: About 12 min Difficulty: Intermediate+

After mastering the basics of permission management, it's time to develop "the ability to make situational decisions." chmod, chown, and sudo are all useful commands. But using them in the wrong order, or without a clear criterion, leads to real damage.

Terms used in this article (defined up front)

• Permission: the setting that decides who may read, write, or execute a file. Also called an "access right"
• owner / group / other: the three classes a permission can apply to — the owning user, members of the owning group, and everyone else. In chmod they are written u / g / o
• r / w / x: read, write, and execute. On a directory, x means something different (covered below)
• Symbolic vs. numeric notation: chmod u+w is symbolic. chmod 644 is numeric, also called octal notation
• umask: the value subtracted from the permissions given to newly created files
• root: the administrator account that can do anything. sudo means "run this one command as root"

The Decision Framework (TL;DR)

When you encounter a permission issue, follow this order—never deviate.

1. Check owner, group, and permissions with ls -l
2. Determine if you are the owner / group / other
3. Choose your fix:
   • Add permissions → chmod
   • Change owner → chown
   • Temporary bypass → sudo (last resort)

Using chmod with Judgment

Conclusion: Prefer symbolic notation; use numeric only when you can explain 644 or 755.

Start with Symbolic Notation (Safety First)

$ chmod u+w report.txt

-rw-r--r-- 1 user user 2048 report.txt

• Adds write permission (w) to the owner (u)
• It changes exactly one thing. The scope of impact is limited, which is why it is less prone to accidents

Why It's Safe

• Target (u/g/o) is explicitly specified
• Less likely to overwrite existing permissions

Dangerous Example: Careless Numeric Notation

$ chmod 777 report.txt

The Problem

• Gives everyone, including other, read, write, and execute permissions
• Anyone who can log into the same server can rewrite the contents
• That leads to unintended modification, or to running a script somebody replaced

Why is chmod 777 Dangerous? (Deep Dive)

777 = Anyone Can Do Anything

• Grants read + write + execute to everyone
• On shared servers, other users could inject malicious code

Real-World Incident

A case where /var/www was set to 777 on a production server:

• Attacker modified PHP files
• Planted a web shell (remote control tool)
• Entire server was compromised

Safe Alternatives

• Directories: 755 (owner writes, others read/execute)
• Files: 644 (owner writes, others read only)
• If a web server needs to write somewhere, match the owning group and grant just that with chmod g+w

When you are tempted to try 777 anyway

777 does not remove the permission problem. It removes the permission check. Run ls -l and id first to see whether you are owner, group, or other. The correct fix is to add the single bit the right party actually needs.

umask: What Determines Default File Permissions

Why Are New Files Created with 644?

umask "subtracts" permissions from the default. It is the value taken away from the permissions a new file would otherwise get.

$ umask

0022

How to think about it: a mask, not subtraction

umask removes the permission bits you name. It is not arithmetic subtraction. With 022 the result happens to match subtraction, but other values do not.

Working out umask 077 as "666 - 077" breaks down because of the borrow. Read it as dropping the named bits, not as subtracting digit by digit.

Figure 1: umask 022 drops only the w bits of group and other. What survives becomes 644, the permission a new file gets. The rows are not being subtracted — the named positions are simply cleared (this is the file case; directories start from 777 and end at 755).

Practical Use Cases

• Allow group write in shared directories → umask 002
• Restrict others from reading for security → umask 077

Directory Permission Pitfalls (Most Common Advanced Mistake)

Conclusion: Directory x lets you enter; missing x blocks cd — add only minimum needed.

dr--r--r-- 2 user user 4096 logs/

Symptom

• ls logs works (you can read the names inside)
• ls -l logs prints the names but shows ? for size and date, because it cannot stat the files inside
• cd logs fails with Permission denied

Reason

• On a directory, x means "permission to enter." That is a different meaning from x (execute) on a file
• On a directory, r means "permission to list the names inside." With r alone you can neither cd into it nor open the files it holds

Solution

$ chmod u+x logs

chown: Ownership Change as Last Resort

Conclusion: Use chown only when ownership is clearly wrong; -R can break service accounts.

When to Use It

$ sudo chown user:user app.log

Use it only when ownership is clearly wrong. Do not change ownership merely because a permission error appeared.

A Common Disaster

$ sudo chown -R user:user /var/www

What Happens

• The web server runs as a dedicated account such as www-data
• That account can no longer read the files
• The web server stops serving

Do this before you run it

1. Record current ownership with ls -ld <target directory>
2. Drop -R and try a single file first
3. List what would change, e.g. find /var/www ! -user www-data | head

The chown -R Disaster (With Recovery Steps)

What Actually Happened

Someone ran chown -R myuser on /var/www:

• Apache/Nginx runs as www-data
• Config files and logs became inaccessible
• Web service went completely down

Recovery Steps

# Restore web content ownership
$ sudo chown -R www-data:www-data /var/www/html

# Verify ownership
$ ls -la /var/www/html/

Lessons Learned

• -R (recursive) has a massive blast radius
• Always check targets with ls -la before running
• Be extra careful with service directories

sudo is Not Magic

Conclusion: sudo is a temporary bypass; permanent fixes use chmod or chown, not sudo chains.

$ sudo rm important.txt

• Being able to run it and being right are two different things
• sudo does not remove the cause. It only hides it

The Right Mindset

• sudo is a temporary bypass
• The permanent fix is chmod or chown
• Before typing sudo, check that you can state in one sentence why your own permissions are not enough

The sudo Spiral: Point of No Return

Common Pattern

1. Permission denied appears
2. "Just sudo it" and move on
3. Created file is now owned by root
4. Can't edit it as your user
5. "sudo again" to edit...
6. Before you know it, everything is root-owned

Figure 2: A file created by sudo belongs to root. Your next edit is rejected, so that same user reaches for sudo again. That loop is what keeps "just sudo it" alive.

Real Example

# Create a new file under sudo...
$ sudo vim new-config.yaml

# and it belongs to root
$ ls -l new-config.yaml
-rw-r--r-- 1 root root 1024 new-config.yaml

# Now you can't edit it as yourself
$ vim new-config.yaml
# Permission denied...

Editing an existing file of your own with sudo vim does not change its owner — vim restores the original owner when it writes the file back. Root-owned files pile up when a command run under sudo creates a file. sudo touch, sudo cp, and a redirect such as sudo command > file all create root-owned files for the same reason.

The Right Approach

• Before using sudo, ask "why don't I have permission?"
• Edit system files with sudoedit (sudo -e). The file keeps its original owner
• Check ownership with ls -l afterwards. If a file ended up root-owned, restore it with sudo chown $USER <file>

Alternative: Design Without Ownership Headaches

Preventing Permission Problems in the First Place

1. Align the Execution User

Configure your application to write to directories owned by the user running it.

2. Solve with Group Permissions

# Create a developers group
$ sudo groupadd developers

# Add users to the group
$ sudo usermod -a -G developers user

# Change directory group
$ sudo chgrp developers /path/to/project
$ sudo chmod g+w /path/to/project

A group added with usermod does not apply to your current session. Log out and back in, then confirm with groups.

3. Configure the Application

Point log output and temp files somewhere the running user can write. The closer they are to that user's own directories, the fewer permission problems appear.

Error Message Triage (Concrete Examples)

Conclusion: On Permission denied, check ls -l to find owner and permissions, then fix.

Case 1: Permission denied

$ echo test > report.txt

Permission denied

Investigation Steps

$ ls -l report.txt

-r--r--r-- 1 user user 2048 report.txt

Decision

• If you are the owner → chmod u+w solves it
• If the owner is someone else → look for a group-based fix first. Consider chown or sudo only when that is not enough

Case 2: Operation not permitted

$ chown user:user system.conf

Operation not permitted

Cause

• Changing ownership requires root. A regular user cannot hand even their own file to somebody else

Decision

• Do you really need to change ownership?
• Can you articulate why sudo is necessary?

Disaster Case: chmod -R Gone Wrong

The Worst Case Scenario

# Setting entire directory to 777...
$ chmod -R 777 .

What Happens

• It reaches everything under the current directory, hidden ones such as .git and .ssh included
• Every file in every subdirectory becomes world-writable
• If ~/.ssh was in scope, SSH refuses keys whose permissions are too loose, so key-based login stops working

Prevention

• Always inspect targets with ls -la before using -R
• Run it without -R on one file or one directory first
• Verify the result, then expand the scope
• Files and directories need different bits. Do not set them together: use find . -type f -exec chmod 644 {} + and find . -type d -exec chmod 755 {} +

Practice Exercise (10 min)

Conclusion: Experience a permission error, read ls -l output, and pick the right fix.

Run the following commands to experience a permission error firsthand. They create a fresh working directory, so nothing existing is touched.

$ mkdir perm-adv
$ cd perm-adv
$ touch test.txt
$ chmod u-w test.txt
$ echo test > test.txt

Check Points

1. Did you get Permission denied?
2. Can you explain why by looking at ls -l?
3. Can you determine which command will fix it?

Next Reading

Conclusion: Next: practice permission operations safely in the virtual terminal.

Apply the "decision framework" you learned in this article in an actual terminal. Penguin Gym Linux provides a virtual environment where you can practice permission operations without any risk to a real machine.

• Permissions (Practical) - Troubleshooting
• Permissions (Basics) - chmod, ls -l basics
• Basic Commands