Permission denied

1 The file belongs to another user

Permissions are checked against a single audience: owner if the UIDs match, otherwise group, otherwise "others". Files created by root or by a service are frequently not yours.

$ ls -l thefile && id

$ sudo chown youruser:yourgroup thefile

On a server, think before taking ownership of files a service needs. Often the correct fix is the opposite: give them to the service user.

2 You are trying to run a file that is not executable

Executability is a permission bit, not a file extension. A freshly downloaded or copied .sh has no execute bit.

$ ls -l script.sh

$ chmod +x script.sh

Or bypass it entirely by invoking the interpreter: bash script.sh.

3 A directory in the path is not traversable

To reach a file you need execute permission on every directory above it. A perfectly readable file inside a 750 directory you have no access to is unreachable — and the error only mentions the file.

$ namei -l /full/path/to/file

$ sudo chmod o+x /the/blocking/directory

namei -l prints the permissions of each path component in order. The first line you cannot pass is your culprit.

4 Writing to a system location without sudo

Everything under /etc, /usr, /var and / itself belongs to root by design.

$ ls -ld /the/directory

$ sudo the-command

Careful: sudo cmd > /etc/file still fails, because your shell performs the redirection. Use: echo data | sudo tee /etc/file.

5 The filesystem is mounted read-only

After a disk error Linux may remount a filesystem read-only to protect it. Then nothing can be written, no matter who you are — including root.

$ mount | grep " / " && dmesg | tail -20

$ sudo mount -o remount,rw /

This is a symptom, not the problem. Check dmesg for disk errors before assuming it is fixed.

6 The disk is full or the quota is exhausted

Some tools report "Permission denied" when what actually failed was the write itself.

$ df -h . && quota -s 2>/dev/null

$ See the dedicated page on "No space left on device".