Linux 'Permission Denied' Error: 3 Quick Fixes

Cause #1: Wrong file or directory permissions

This is the one you'll see most often. You try to run a script or open a file and get bash: ./script.sh: Permission denied or cat: /etc/shadow: Permission denied. The issue is simple: the file doesn't have the right read, write, or execute bits set for your user.

First, check the current permissions with ls -l:

ls -l /path/to/file

You'll see something like -rw-rw-r--. The first character is the file type. The next three are the owner permissions, then group, then everyone else. If you're the owner and you don't have execute (x), you can't run it. If you're not the owner and the file doesn't have world-read, you can't read it.

The fix: Use chmod to add the right permission.

• To make a script executable for the owner: chmod u+x script.sh
• To give read access to everyone: chmod o+r file.txt
• To give owner full control, group read/execute, and others none: chmod 750 file

After running chmod, run ls -l again. You should see the permission string changed. Try your command again.

Real-world scenario: You download a Python script from a repo, try python script.py, and it fails. Check permissions – it probably has 644 (owner write, everyone read). You don't need execute for a Python script you're passing to the interpreter, but if the file itself is read-locked for your user, chmod +r fixes it. Or if it's meant to be run directly (./script.py), you need chmod +x script.py.

One more thing: if the file is owned by root and you're a regular user, chmod won't work without sudo. Run sudo chmod 755 file if you're sure it's safe. Be careful – don't make system files world-writable.

Cause #2: You don't own the file (wrong user/group)

This is the second most common. You try to edit a config file or delete a log, and get Permission denied even though the file permissions look fine. The problem: the file belongs to another user, and you don't have group or world access.

Run ls -l again. Look at the third and fourth columns – owner and group. If it says root root and you're logged in as john, you can't touch it unless the permissions explicitly allow it.

The fix: Use chown to change the owner, or chgrp to change the group.

• Change owner to yourself: sudo chown john file.txt
• Change group so your user is in it: sudo chgrp developers file.txt
• Change both at once: sudo chown john:developers file.txt

After changing ownership, run ls -l to confirm. Then try your action again.

Real-world scenario: You're setting up a web server and need to edit /etc/nginx/nginx.conf. It's owned by root. You could sudo nano /etc/nginx/nginx.conf instead of changing ownership – that's safer. But if you're managing a shared directory where multiple users need write access, chown the directory to a group and set the group writable bit (chmod g+w). That way everyone in the group can edit files without being root.

Skip changing ownership of system files just to avoid sudo. That's a bad habit – you'll break updates and security. Use sudo for the occasional edit instead.

Cause #3: Filesystem is mounted read-only

This one catches people off guard. You try to write a file or create a directory, and get Permission denied even though you own the directory and permissions are 777. The problem: the whole filesystem is mounted read-only.

Check the mount status with mount | grep "on / " or mount | grep "your/mount/point". Look for ro in the options list – that means read-only.

The fix: Remount the filesystem with read-write permissions.

For the root filesystem:

sudo mount -o remount,rw /

For any other mount point:

sudo mount -o remount,rw /path/to/mountpoint

After running that, try your write operation again. It should work.

Real-world scenario: You boot into recovery mode to fix a broken system, and the root filesystem is mounted read-only by default. You try to edit /etc/fstab and get Permission denied. The fix above works instantly. Or, you plug in a USB drive and it mounts read-only because the filesystem has errors. Run sudo fsck /dev/sdb1 (replace with your device) to fix the errors, then remount with read-write.

Another case: Docker containers or virtual machines sometimes mount volumes read-only for security. Check your docker-compose.yml or VM config – you might need to add :rw to the mount option.

Quick-reference summary table

That's it. Three causes, three fixes. Start with permissions, then ownership, then mount options. You'll fix 99% of 'Permission denied' errors this way.