How to Use chmod and chown - Linux File Permissions Guide

2025-01-11 Reading time: About 12 min Difficulty: Beginner

What you'll learn:

• Diagnose issues by reading ls -l output
• Choose between chmod / chown and apply the right fix
• Graduate from blindly using "sudo for everything"

Target Audience: Beginners starting to work with Ubuntu servers

Note: Some operations require sudo

Decision Flow (Quick Reference)

Conclusion: On Permission denied, check ls -l then pick chmod, chown, or sudo accordingly.

When you encounter "Permission denied", check this table from top to bottom.

First, Learn to Read ls -l (Most Important)

Conclusion: 90% of permission issues show their cause in ls -l — learn to read it first.

90% of permission issues can be diagnosed with ls -l. Once you can read this, you can graduate from "blindly using sudo".

$ ls -l sample.txt

-rw-r--r-- 1 user user  1234 Dec 17 12:00 sample.txt

Why this order?: Permission errors are about the combination of "who" can do "what". Following this order lets you logically diagnose the cause.

Understand rwx as "Decision Criteria"

Conclusion: Read owner/group/other permissions to determine what each role can do.

Example: rw-r--r--

chmod: Start with Symbolic Notation (Accident Prevention)

Conclusion: Use symbolic notation like u+w by default; numeric only when you can explain it.

Basic Usage

$ chmod u+w sample.txt

Meaning:

• u (owner)
• w (write)
• Add permission

Why symbolic notation is safer: It clearly shows "what changed". chmod u+w is more explicit than chmod 644, making it easier to catch mistakes during code review.

$ chmod 777 sample.txt

Why is chmod 777 dangerous?

777 means "anyone can read, write, and execute".

Real-World Incident

A production web server had /var/www/html set to chmod -R 777. Result:

• Attacker uploaded a PHP file
• That PHP was executed, compromising the server
• Customer data leaked, service went down

Why the Attack Succeeded

777 = giving w (write) and x (execute) to other (everyone). Files could be placed via the web server and executed.

Safe Alternatives

How to read numeric notation: r=4, w=2, x=1 summed together. For example, 755 = rwx(7) + r-x(5) + r-x(5) = owner has all permissions, group and others can only read and execute.

Watch Out for Directory Execute Permission

Conclusion: Directory x means enter permission; missing x blocks cd — add only the minimum.

drwxr-xr-x 2 user user 4096 Dec 17 12:10 mydir

• Directory x: determines if you can enter (can you cd into it)
• r alone is not enough for cd (you can see file list but can't enter)

chown: Change Ownership Carefully

Conclusion: Change ownership only when clearly needed; -R can break service accounts.

Basic Usage

$ sudo chown user:user sample.txt

Why sudo is required: Changing ownership is a system administration operation. It would be dangerous if any user could claim ownership of others' files.

How chown -R broke production (with recovery)

What Happened

$ sudo chown -R myuser:myuser /var/www/html

Wanted to "edit my own files". Result:

• Apache/Nginx runs as www-data user
• After ownership change, web server couldn't read files
• Site showed 403 Forbidden

Recovery

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

Correct Approach

If you want to edit files, instead of changing ownership:

• Add yourself to the www-data group
• Or use sudo -u www-data vim file.php to edit

sudo Is Not Magic

Conclusion: sudo masks root cause; diagnose with ls -l first, then use sudo only if needed.

• sudo = simply runs as root
• Can mask underlying permission design issues

$ sudo chmod 777 ...

Real incidents from sudo abuse

Incident Pattern 1: Can't edit file anymore

$ sudo vim config.yaml

Later, trying to edit normally with vim config.yaml:

E45: 'readonly' option is set (add ! to override)

Cause: Opening with sudo made it root-owned (or .swp file was created as root)

Solution

• sudo chown $USER:$USER config.yaml to restore ownership
• Or use sudoedit config.yaml (sudo -e) from the start

Incident Pattern 2: Home directory becomes root-owned

$ sudo chown -R root:root ~

Result: Can't login, .bashrc unreadable, SSH keys don't work.

Recovery: From another root session: chown -R user:user /home/user

Common Permission Denied Troubleshooting

Conclusion: Check ls -l to identify your role and ownership, then apply the right fix.

Case 1: Cannot Write to File

$ echo "test" >> /etc/hosts

-bash: /etc/hosts: Permission denied

Diagnosis

$ ls -l /etc/hosts

-rw-r--r-- 1 root root 221 Dec 17 10:00 /etc/hosts

Cause

• Owner is root
• You are in other position → r-- (read only)

Common Misconception

"Just use sudo" → Half right, half wrong

/etc/hosts is a system file, intentionally writable only by root. Using sudo to edit is correct, but understand "why it's protected" before doing so.

Case 2: Cannot Execute Script

$ ./deploy.sh

-bash: ./deploy.sh: Permission denied

Diagnosis

$ ls -l deploy.sh

-rw-r--r-- 1 user user 1234 Dec 17 11:00 deploy.sh

Cause

• Permissions are rw-r--r-- → no execute permission (x)
• You're the owner but still can't execute

Fix

$ chmod u+x deploy.sh
$ ./deploy.sh

Why this is safe: u+x only grants execute permission to the owner. Doesn't affect other users, so it's a minimal change.

Case 3: Cannot Enter Directory

$ cd /var/log/nginx

-bash: cd: /var/log/nginx: Permission denied

Diagnosis

$ ls -ld /var/log/nginx

drwxr-x--- 2 www-data adm 4096 Dec 17 10:00 /var/log/nginx

Cause

• Permissions are rwxr-x--- → nothing allowed for other
• You're not www-data or in adm group

Fix Options

1. sudo cd doesn't work (cd is shell built-in) → Use sudo ls /var/log/nginx to view contents
2. Add yourself to adm group: sudo usermod -aG adm $USER (requires re-login — group information is loaded at login time)

Permission Diagnosis Checklist

Conclusion: Confirm identity with whoami and groups, then check ls -l to pick the right fix.

When you encounter "Permission denied", check the following in order.

Step 1: Verify Your Identity

• Checked your username with whoami
• Checked your group memberships with groups

Step 2: Check File/Directory Status

• Checked permissions and owner with ls -l filename
• Determined whether you are owner / group / other
• Verified if required permission (r/w/x) is granted for your position

Step 3: Choose Resolution Method

• Insufficient permission → Add with chmod
• Different owner → Change with chown (requires sudo)
• System file → Use sudoedit or sudo

Step 4: Verify Changes

• Confirmed changes with ls -l again
• Verified the intended operation succeeds
• Confirmed no excessive permissions (like 777) were granted

Practice Exercise (5 min)

Conclusion: Remove write permission, hit the error, then recover to learn the fix.

$ mkdir ~/perm-test
$ cd ~/perm-test
$ touch a.txt
$ ls -l
$ chmod u-w a.txt
$ echo "test" > a.txt

Expected Result:

• You get "Permission denied"
• You can explain from ls -l that "I'm the owner but w permission is missing"

Recovery:

$ chmod u+w a.txt
$ echo "test" > a.txt
$ cat a.txt

test

Next Reading

Conclusion: Practice permission operations in the virtual terminal to build the habit.

Once you've learned the "decision pattern" introduced in this article, solidify your skills with hands-on practice at Penguin Gym Linux.

Command Quick Reference

• Permissions (Advanced) - Decision patterns
• How to Fix Permission Denied
• Top 10 Essential Commands