Linux Permission Basics: Learn to Fix "Permission Denied" On Your Own

Permission Basics - Understanding Permissions
Reading time: ~12 min Level: 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

The Decision Pattern (TL;DR)

1) Check owner/permissions with ls -l → 2) Determine if you're owner/group/other → 3) Choose chmod, chown, or sudo

Table of Contents

  1. First, Learn to Read ls -l (Most Important)
  2. Understand rwx as "Decision Criteria"
  3. chmod: Start with Symbolic Notation (Accident Prevention)
  4. Watch Out for Directory Execute Permission
  5. chown: Change Ownership Carefully
  6. sudo Is Not Magic
  7. Common Permission Denied Troubleshooting
  8. Practice Exercise (5 min)
  9. What to Read Next

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

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

Reading Order (Always Follow This)

  1. First character: - / d (file or directory)
  2. Permissions: rw-r--r--
  3. Owner: user
  4. Group: user

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"

Example: rw-r--r--

Target Permissions What You Can Do
owner rw- Read/write OK, execute NG
group r-- Read only
other r-- Read only

Decision Example

  • If you're the owner → can write
  • If group/other → can only read, cannot write

To check your position, use whoami and groups.

chmod: Start with Symbolic Notation (Accident Prevention)

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.

Common Accident

$ chmod 777 sample.txt

Problems:

  • Often executed without understanding
  • Opens up permissions unnecessarily

→ Numeric notation can wait. Start with symbolic notation.

▶ Why is chmod 777 dangerous? (Click to expand)

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

TargetRecommendedReason
Directories755Only owner can write
Files644Only owner can write
Private keys600Only owner can access

Watch Out for Directory Execute Permission

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)

Common Issue

Can ls but can't cd

→ Most likely missing x permission on directory

Fix: chmod u+x mydir

chown: Change Ownership Carefully

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.

Common Accidents

  • chown -R myuser on everything under /var/www → Web server stops working
  • Changing to root ownership and can't revert

Mindset: Always ask "Why do I need to change ownership?"

▶ 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

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

Anti-Pattern

$ sudo chmod 777 ...

"Got Permission denied so used sudo" "Still didn't work so used 777". This is the worst pattern. Creating a security hole without understanding the cause.

Recommended Approach

  • First diagnose with ls -l
  • Use sudo only when necessary
  • Be able to explain why sudo is needed before using it
▶ 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

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)

Practice Exercise (5 min)

$ 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

What to Read Next

Verification Environment

Commands in this article were verified on Ubuntu 24.04 LTS / bash 5.2.

Master Permission Management Through Practice

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

Practice at Penguin Gym Linux Next Article: Permissions Advanced