Fix 'Permission denied' on Linux | Quick Steps

You're in the terminal, you type ls and see a file. You try cat file.txt and get:

cat: file.txt: Permission denied

Or maybe you tried to copy something to /usr/local/bin and got the same error. This pops up on Ubuntu 22.04, Fedora 39, Debian 12 — basically any Linux system. It means your user doesn't have the right access.

Don't panic. Most of the time this is a quick fix. We'll start with the fastest thing you can try, then move to deeper fixes if you need them.

Quick fix (30 seconds) — use sudo if it's a system file

If the file is in a system folder like /etc, /usr, or /var, your regular user account just can't write there. That's by design. The fix:

Open a terminal.
Type sudo before your command. So instead of cat /etc/shadow, type sudo cat /etc/shadow.
When prompted, type your password (you won't see the characters as you type — that's normal). Press Enter.

What you'll see: If the password is correct, the command runs. If it's wrong, you'll get Sorry, try again. Three wrong tries and it kicks you out. Type the command again if that happens.

This works for any file you need to read, edit, or delete that belongs to root or another system user. But if you're trying to read a file in your own home directory (/home/yourname) and still get the error, sudo won't help. Move to the next fix.

Moderate fix (5 minutes) — check and change file permissions

Sometimes the file exists but the permissions are too restrictive. Let's check.

Step 1: See what's going on

In the terminal, run:

ls -l /path/to/your/file

You'll see something like:

-rw------- 1 root root 1234 Mar 15 10:30 file.txt

The first part -rw------- tells the story. The first character is - for a regular file or d for a directory. Then three groups of three: owner, group, others. rw- means read and write, no execute. --- means no permissions at all.

If it shows rw-------, only the owner (root in this example) can read or write it. You're not root, so you're locked out.

Step 2: Change permissions with chmod

If you own the file or have sudo access, use chmod. For a file you want to read but not change:

chmod 644 /path/to/file

That gives owner read+write, group and others read-only. After running this:

ls -l /path/to/file

Should show -rw-r--r--. Now try cat /path/to/file again. It should work.

If it's a script you want to run, add execute:

chmod 755 /path/to/script.sh

That makes it -rwxr-xr-x. Everyone can read and execute, only owner can write.

Real-world trigger: I've seen this on Ubuntu 22.04 when you download a script from a website or clone a repo. The file comes with 644 or 600 permissions. You try ./script.sh and get Permission denied. Run chmod +x script.sh to add execute.

Advanced fix (15+ minutes) — fix ownership or SELinux

If permissions look fine but you still can't access the file, the problem is ownership or SELinux/AppArmor.

Check ownership

Run:

ls -l /path/to/file

Look at the owner and group columns. If it says root root and you're not root, you can't write to it unless you use sudo. But if it says username username where username isn't you, then the file belongs to another user. You need to change it.

To take ownership with sudo:

sudo chown yourusername:yourusername /path/to/file

Replace yourusername with your actual login name. Check with whoami if you're not sure.

After this, ls -l should show your name. Try the command again.

Check SELinux (Fedora, RHEL, CentOS)

SELinux is a security layer that can block access even when file permissions are wide open. On Fedora 39 or RHEL 9, you might see this with web server files or custom scripts.

First, check if SELinux is enforcing:

getenforce

If it says Enforcing, SELinux is on. Check the context of your file:

ls -Z /path/to/file

You'll see something like unconfined_u:object_r:user_home_t:s0. If the context is wrong (like user_home_t for a file in /var/www/html), that's your problem.

Fix it by setting the correct context. For a web file in /var/www/html:

sudo chcon -t httpd_sys_content_t /var/www/html/index.html

Or restore the default context for the whole directory:

sudo restorecon -Rv /var/www/html

After this, try accessing the file again. If it works, consider adding a permanent rule with semanage if you need it often.

Check AppArmor (Ubuntu, Debian)

Ubuntu uses AppArmor instead of SELinux. It's less common to block regular files, but it can happen with custom applications.

Check if AppArmor is blocking:

sudo aa-status

Look for your application in the list. If you see it, you can temporarily disable the profile for testing:

sudo aa-complain /path/to/application

That sets it to complain mode — it logs violations but doesn't block. If the file works now, the profile is too strict. You'll need to edit the profile in /etc/apparmor.d/ which is beyond this guide.

When none of these work

If you still get Permission denied after trying all three fixes, here's what to check:

Is the file on a mounted drive? Check with mount. If it's an NTFS or FAT32 drive, try mounting with uid=youruser,gid=youruser options.
Is the filesystem full? df -h shows disk usage. If it's 100% full, you can't write new files until you free space.
Is there a filesystem error? Run fsck on the partition (requires unmounting first).

Most of the time, one of the steps above will fix it. Start with sudo, then check permissions, then ownership. SELinux and AppArmor are rare for regular users but common when setting up servers.