Fix 'Permission Denied' in Linux Terminal (chmod & sudo)

1. File Permissions: The Usual Suspect

Nine times out of ten, 'Permission denied' is just the file or directory not being readable, writable, or executable by your user. Classic example: you download a script, try to run it with ./script.sh, and get bash: ./script.sh: Permission denied. That's not a broken file — it's missing the execute bit.

Check the current permissions with ls -l. The first column shows things like -rw-r--r--. The x means execute. If you don't see an x for your user (the first triplet), that's your problem.

The fix: Add execute permission with chmod.

chmod +x script.sh

Or if you own the file and want to set specific permissions (read/write/execute for you, read/execute for group and others):

chmod 755 script.sh

For directories, you need execute to cd into them and read to list contents. A directory with drwx------ only lets the owner in. If you're getting 'Permission denied' when trying to cd into a directory you own, check the permissions with ls -ld dirname.

Real-world trigger: You clone a repo from GitHub, try to run a build script, and get this error. The repo files usually come with default permissions that don't include execute.

Don't bother with chmod 777 as a blanket fix. That gives everyone full access — a bad idea on any shared system. Only use it for temporary testing, and even then, be careful.

2. You Don't Have sudo (or You're Using It Wrong)

Second most common: the operation needs root privileges and you're not using sudo. Editing files in /etc, installing packages, managing services — all require root.

If you get Permission denied when trying to write to a system file, you probably need to prefix your command with sudo:

sudo nano /etc/hosts

But there's a catch. If your user isn't in the sudo group, you get user is not in the sudoers file — that's a different error. If you are in the sudo group and still get permission denied, check that you're actually using sudo and not just typing su without arguments (which switches to root but only works if you know the root password).

Another gotcha: Redirection with sudo doesn't work as you'd expect. This fails:

sudo echo "nameserver 8.8.8.8" > /etc/resolv.conf

Why? Because the shell does the redirection before sudo runs, and your user doesn't have write permission to that file. You'll see Permission denied from the shell, not sudo. The workaround is to use tee:

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

That's a classic mistake even experienced admins make occasionally.

Real-world trigger: You're setting up a web server, try to edit /etc/nginx/nginx.conf with nano, and get permission denied. You need sudo nano.

3. Ownership and Mount Options (The Sneaky Ones)

Sometimes the permissions look right, but you still get denied. Two culprits here: file ownership and mount options.

Ownership: If a file is owned by root:root and you're not root, even with rwxrwxrwx permissions, you might hit ACLs or selinux, but more commonly it's just that you're not in the right group. Check ownership with ls -l — the third and fourth columns. To change ownership, you need root:

sudo chown youruser:yourgroup file.txt

For directories, you might need to recursively change ownership:

sudo chown -R youruser:yourgroup /path/to/dir

Mount options: If you're on an external drive, USB stick, or a secondary partition, check how it's mounted. Run mount | grep /media/yourdrive. If you see ro (read-only), you can't write to it, no matter what the permissions say. The fix is to remount with write access:

sudo mount -o remount,rw /media/yourdrive

Or if it's an NTFS drive, you might need ntfs-3g to get proper write support. The default mount might be read-only due to a dirty Windows shutdown.

Real-world trigger: You plug in a USB drive from a friend, try to copy a file to it, get 'Permission denied' even though you're the owner and permissions look fine. Check mount options first.

Quick Reference Table