Linux Permissions Practical: Solving "Permission denied" at the Root Cause

Permissions Practical - Solving Permission denied at the root cause
Reading time: ~12 min Difficulty: Intermediate

When you see "Permission denied", do you immediately reach for sudo? That's not solving the problem—it's just postponing it. This article teaches you the "proper diagnosis" and "permanent fix" patterns through real-world scenarios.

Table of Contents

  1. The Decision Pattern (Conclusion First)
  2. Case 1: Can't Write to Log File
  3. Case 2: Can't Create File in Directory
  4. Case 3: Can't Execute Script
  5. Think Before Using sudo
  6. Practice Exercises (10 min)
  7. What to Read Next

1. The Decision Pattern (Conclusion First)

When you encounter Permission denied, diagnose with these 3 steps:

  1. Clarify what you tried to do (read / write / execute)
  2. Check the target's permissions and owner with ls -l
  3. Determine if you're the owner / group / other, and choose the minimal fix

"Just use sudo" and "Just chmod 777" are forbidden. The golden rule is: identify the cause first, then apply the minimal fix.

Decision Flow in Practice

# Step 1: Reproduce the error
$ echo "log" >> /var/log/app.log
Permission denied

# Step 2: Check the target
$ ls -l /var/log/app.log
-rw-r----- 1 app-user app-group 1234 /var/log/app.log

# Step 3: Check who you are
$ id
uid=1000(developer) gid=1000(developer) groups=1000(developer)

# Conclusion: Joining the group solves it
$ sudo usermod -a -G app-group developer

2. Case 1: Can't Write to Log File

Symptoms

$ echo "test log" >> /var/log/myapp.log
bash: /var/log/myapp.log: Permission denied

Diagnosis Steps

# Check file permissions
$ ls -l /var/log/myapp.log
-rw-r----- 1 root adm 2048 /var/log/myapp.log

# Check your groups
$ groups
developer

Analysis

  • File is owned by root:adm
  • Group adm has no write permission (r--)
  • You're not even in the adm group

Solutions (Choose Based on Situation)

A: Change the Application Configuration (Recommended)

Change the log output destination to a location you have permissions for.

# Change log path in app config
LOG_PATH=/home/developer/logs/myapp.log

B: Get Added to the Group

# Add to adm group (requires re-login)
$ sudo usermod -a -G adm developer

C: Change the Owner (Last Resort)

# Change ownership
$ sudo chown developer:developer /var/log/myapp.log

Best Practice: For application logs, it's safer to create a dedicated directory (e.g., /var/log/myapp/) with appropriate ownership rather than placing files directly in /var/log/.

3. Case 2: Can't Create File in Directory

Symptoms

$ touch /var/www/html/newfile.html
touch: cannot touch '/var/www/html/newfile.html': Permission denied

Diagnosis Steps (This Is Key)

# File doesn't exist → directory permissions are the issue
$ ls -ld /var/www/html/
drwxr-xr-x 2 www-data www-data 4096 /var/www/html/

Analysis

  • Directory is owned by www-data:www-data
  • Others have r-x (read and execute only, no write)
  • Creating files requires write permission (w) on the directory

Solutions (Choose Based on Situation)

A: Join the www-data Group (Recommended)

# Add to group
$ sudo usermod -a -G www-data developer

# Grant write permission to group
$ sudo chmod g+w /var/www/html/

B: Create a Separate Dev Directory

# Create dev directory with your ownership
$ sudo mkdir /var/www/html/dev
$ sudo chown developer:developer /var/www/html/dev

Never do this: chmod 777 /var/www/html/. This dramatically increases security risk.

▶ Accident Case: chmod -R Gone Wrong

A Real Incident

# Accidentally ran on production server
$ sudo chmod -R 777 /var/www/

What Happened

  • All files became world-writable
  • Malicious scripts were planted
  • Server became a stepping stone for attacks

Lessons Learned

  • Always verify the scope before using -R
  • Test on a single file/directory first
  • Be extra careful on production servers

4. Case 3: Can't Execute Script

Symptoms

$ ./deploy.sh
bash: ./deploy.sh: Permission denied

Diagnosis Steps

$ ls -l deploy.sh
-rw-r--r-- 1 developer developer 512 deploy.sh

Analysis

  • You're the owner
  • No execute permission (x) (rw-r--r--)

Solution

# Add execute permission for owner
$ chmod u+x deploy.sh

# Verify
$ ls -l deploy.sh
-rwxr--r-- 1 developer developer 512 deploy.sh

# Execute
$ ./deploy.sh

Alternative: Run with bash Directly

Even without execute permission, you can run scripts by explicitly calling the interpreter.

$ bash deploy.sh

However, this is a temporary workaround. Proper permission settings are recommended for production use.

5. Think Before Using sudo

sudo is a powerful tool, but it's not a magic wand that solves everything.

When to Use sudo

  • Changing system configurations (/etc/ files, etc.)
  • Installing packages
  • Starting/stopping services

When NOT to Use sudo

  • Editing your own work files
  • Running development applications
  • Just because you want to "make it work somehow"
▶ Accident Case: Root-Owned Files Proliferate

Common Pattern

# Permission denied during development
$ npm install
Permission denied

# "Just use sudo"
$ sudo npm install

# node_modules is now root-owned...
$ ls -ld node_modules/
drwxr-xr-x 500 root root 20480 node_modules/

# Can't run npm install normally anymore!

Why This Happens

  • Running with sudo creates files owned by root
  • Once root-owned, regular users can't overwrite them
  • Using sudo again → more root-owned files... a vicious cycle

How to Fix

# Change ownership back to yourself
$ sudo chown -R $(whoami) node_modules/

# Run without sudo from now on

Prevention

  • Do development work without sudo as a rule
  • When you get Permission denied, investigate the cause
  • npm can use --prefix to specify a local installation directory
▶ Alternative: Design to Prevent Permission Troubles

1. Work in Your Home Directory

Under /home/user/projects/, permission issues rarely occur.

2. Use Development Groups

# Create a group for the dev team
$ sudo groupadd devteam
$ sudo usermod -a -G devteam alice
$ sudo usermod -a -G devteam bob

# Manage project directory with group
$ sudo chgrp devteam /var/www/project
$ sudo chmod g+w /var/www/project
$ sudo chmod g+s /var/www/project  # New files auto-inherit devteam ownership

3. Change Paths with Environment Variables

Set output destinations for logs, cache, and temp files to locations you have permissions for.

6. Practice Exercises (10 min)

Try the following scenarios in order to experience the "diagnose → analyze → solve" flow.

Exercise 1: Append to a Read-Only File

$ mkdir perm-practice && cd perm-practice
$ touch readonly.txt
$ chmod u-w readonly.txt
$ echo "test" >> readonly.txt

Check Points

  1. Did you get Permission denied?
  2. Can you identify the cause with ls -l?
  3. Can you decide which command to use?

Exercise 2: Create File in a Directory

$ mkdir restricted
$ chmod u-w restricted
$ touch restricted/newfile.txt

Check Points

  1. Do you understand the error cause is the "directory", not the "file"?
  2. Did you check the directory permissions with ls -ld?

Exercise 3: Execute a Script

$ echo '#!/bin/bash' > test.sh
$ echo 'echo "Hello!"' >> test.sh
$ ./test.sh

Check Points

  1. Can you identify the missing execute permission?
  2. Can you fix it with chmod u+x?
  3. Do you know the alternative bash test.sh?

Solution Approach

  • Exercise 1: chmod u+w readonly.txt
  • Exercise 2: chmod u+w restricted (directory permission)
  • Exercise 3: chmod u+x test.sh or bash test.sh

7. What to Read Next

📋 Verification Environment

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

🔐 Permission Management Series

  1. Basics - Permission concepts, reading ls -l, basic chmod
  2. Advanced - Decision patterns for chmod, chown, sudo
  3. Practical (This Article) - Solving Permission denied at root cause

🎉 Build Your Practical Skills

The habit of asking "why?" instead of reaching for "sudo" when you see Permission denied is what builds real practical skills. Practice safely in Penguin Gym Linux's virtual environment.

🐧 Practice with Penguin Gym Linux 📚 Next Article: Process Management Basics