"Permission denied" is one of the most common Linux errors, and one of the most misunderstood — it can mean several different things depending on context. This guide covers diagnosing the exact cause.
Understanding Linux Permissions
ls -l filename
-rwxr-xr-- 1 owner group filename
The three permission groups (owner, group, others) each control read (r), write (w), and execute (x) access separately.
Case 1 — "Permission Denied" Running a Script
./myscript.sh
bash: ./myscript.sh: Permission denied
The file isn't marked executable:
chmod +x myscript.sh
Case 2 — "Permission Denied" Writing to a File/Directory
touch /var/www/site/test.txt
touch: cannot touch 'test.txt': Permission denied
Check ownership:
ls -la /var/www/site
Fix ownership to match the user/service that needs access:
sudo chown -R www-data:www-data /var/www/site
Or adjust permissions directly:
sudo chmod -R 755 /var/www/site
Case 3 — "Permission Denied" Connecting to Docker
docker ps
permission denied while trying to connect to the Docker daemon socket
Your user isn't in the docker group:
sudo usermod -aG docker $USER
newgrp docker
Case 4 — "Permission Denied" with sudo
username is not in the sudoers file
The account doesn't have sudo privileges — see How to Create a New User with Sudo Access on a Linux VPS.
Case 5 — "Permission Denied (publickey)" via SSH
This is an authentication failure, not a filesystem permission issue — see VPS Unreachable/Can't Connect via SSH: Troubleshooting Guide.
Case 6 — 403 Forbidden from a Web Server
The web server process (typically running as www-data) doesn't have read access to the requested files:
sudo chown -R www-data:www-data /var/www/site
sudo chmod -R 755 /var/www/site
Understanding chmod Numeric Notation
| Number | Meaning |
|---|---|
| 7 | Read + Write + Execute |
| 6 | Read + Write |
| 5 | Read + Execute |
| 4 | Read only |
A common pattern: 755 for directories (owner full access, others read+execute), 644 for files (owner read+write, others read only).
Checking Which User a Process Runs As
ps aux | grep nginx
This confirms which user account actually needs the permission, rather than guessing.
Common Errors
chmod 777 "fixes" the problem — this works but grants write access to every user on the system; always prefer setting the correct owner/group over overly permissive modes.
Permission fix doesn't persist — some deployment scripts or package updates reset ownership; consider setting correct ownership as part of your deployment process.
Best Practices
- Fix ownership (
chown) before resorting to broad permission changes (chmod 777) - Grant the minimum permissions actually required
- Understand which user/service actually needs access before changing anything
Related Articles
- How to Create a New User with Sudo Access on a Linux VPS
- How to Fix Common Nginx Errors (502/504/403)
- VPS Unreachable/Can't Connect via SSH: Troubleshooting Guide
