Ubuntu Permission Denied Fix - chmod, chown, sudo Troubleshooting Guide

Ubuntu Permission Denied Fix - chmod, chown, sudo Troubleshooting Guide
Reading time: About 10 min Difficulty: Intermediate

What You'll Learn

  • How to quickly diagnose Permission denied errors on Ubuntu
  • When to use chmod, chown, or sudo
  • How to avoid common mistakes (like opening permissions too wide)

Quick Summary

Permission denied usually falls into one of these categories:

  1. No execute permission -> chmod +x
  2. Wrong owner/group -> chown / chgrp
  3. Requires admin privileges -> Run with sudo
  4. Can't enter directory (no x permission) -> Check directory permissions

Start with ls -la (or namei -l) to see who's blocking what.

Prerequisites

  • OS: Ubuntu
  • Shell: bash
  • Permissions: sudo access assumed (contact admin if unavailable)

1. Check the Symptoms

Conclusion: The error type — file, script, or directory — determines which fix path to take.

Example: Can't read a file

$ cat /path/to/file
cat: ...: Permission denied

Example: Can't execute a script

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

Example: Can't enter a directory

$ cd /path/to/dir
bash: cd: ...: Permission denied

2. Check Permissions (ls -la)

Conclusion: Run ls -la — the rwx bits for owner, group, and others reveal what is missing.

$ ls -la /path/to/target

Reading Permissions

  • r: read
  • w: write
  • x: execute (or enter for directories)

Three groups: owner | group | others

Examples:

  • -rw-r--r--: Owner can write, others can only read
  • drwxr-x---: Owner has full access, group can read/enter, others have no access

Case A: Script Won't Execute (no x)

Conclusion: Run chmod +x when the x bit is absent — it adds only execute, nothing else.

Check:

$ ls -la script.sh

If you see -rw-r--r-- (no x), add execute permission:

$ chmod +x script.sh

This only adds "execute" permission. No need to widen read/write permissions.

Case B: Can't Write (no w / wrong owner)

Conclusion: Write access is set by the directory — use chown or sudo accordingly.

Write permissions depend on the directory.

If you should own the location -> Fix ownership (Case C)

If it's a system directory (/etc, /var, /usr) -> Use sudo (Case D)

Case C: Wrong Owner/Group (chown/chgrp)

Conclusion: Use chown user:group /path — always verify the path before adding -R.

Change owner (example: user is ubuntu):

$ sudo chown ubuntu:ubuntu /path/to/dir

Recursive (be careful!):

$ sudo chown -R ubuntu:ubuntu /path/to/dir

Warning: -R affects everything under the path. Double-check before running!

Change group only:

$ sudo chgrp www-data /path/to/dir

Case D: Need Admin Privileges (sudo)

Conclusion: Use sudo for system files — temporary elevated access, ownership unchanged.

System files and services require admin access:

$ sudo vim /etc/nginx/nginx.conf
$ sudo systemctl restart nginx

Case E: Can't Enter Directory (no x)

Conclusion: Directories need x to enter — fix with chown, not chmod 777.

cd permission denied usually means the directory lacks execute (enter) permission.

$ ls -ld /path/to/dir

If you should be able to enter, fix ownership or group (Case C). Do not use chmod 777 carelessly.

3. Trace the Path (namei)

Conclusion: Run namei -l /path — shows each directory's permissions and reveals the block.

When you can't figure out where the block is in a long path:

$ namei -l /path/to/target

This shows permissions for each directory in the path, making it easy to find the problem directory.

4. What NOT to Do

Conclusion: Never use chmod 777 or chown -R / — both create holes or destroy the system.

Next Reading