"Permission denied" means the user you're running as doesn't have rights to that file or folder. Two commands fix almost every case — once you know which one you need.
Quick answer
"Permission denied" on Linux means your user lacks rights to that file or folder. Run ls -l to see the owner and permissions, then either change the owner with chown user:group file or the permissions with chmod — typically 644 for files and 755 for folders and scripts. Avoid chmod 777; it hides the problem and opens a security hole.
First: who owns it and what are its permissions?
Run ls -l to see ownership and permission bits before changing anything:
ls -l start.sh
# -rw-r--r-- 1 gameuser gameuser 482 Jun 12 10:00 start.sh
# ^perms ^owner ^groupCommon chmod values (quick reference)
The three digits are owner / group / others. The common ones:
| chmod | Meaning | Use for |
|---|---|---|
| 755 | Owner full, others read+execute | Scripts, folders, web files |
| 644 | Owner read+write, others read | Normal files, configs |
| 600 | Owner read+write only | Private keys, secrets |
| 700 | Owner full, nobody else | Private folders (~/.ssh) |
| 777 | Everyone full access | Almost never — a security risk |
777 makes a file world-writable — anyone on the server can change it. It hides the real problem (usually wrong ownership) behind a security hole. Fix ownership with chown instead.
Case 1: a script won't execute
"./start.sh: Permission denied" usually means the file isn't marked executable. Add the execute bit:
chmod +x start.sh
./start.shCase 2: wrong owner
If a service runs as gameuser but the files are owned by root, it can't write to them. Give ownership to the right user (recursively for a whole folder):
chown -R gameuser:gameuser /home/gameuser/serverUnderstanding chmod numbers
Permissions are read (4), write (2), execute (1), added per group of owner/group/others:
chmod 755— owner full, everyone else read+execute (good for scripts/folders).chmod 644— owner read+write, others read (good for normal files).chmod 600— owner only (good for keys and secrets).
Setting 777 makes a file writable by everyone — a security hole, not a fix. If 777 "solves" it, the real problem is ownership; use chown instead.
"Permission denied (publickey)" is different
That specific SSH message is about key auth, not files. Your SSH key isn't accepted — check the key is in ~/.ssh/authorized_keys and that .ssh is 700 and the file is 600.
If it won't run, it's usually chmod +x. If a service can't write, it's usually chown. Reach for 777 never.
Case 3: "Permission denied" on a mounted or network drive
On NFS mounts or some network volumes, chmod on the client can be ignored entirely because of root_squash or a UID/GID mismatch between the client and the server exporting the mount. If chmod/chown seem to "not stick", check the mount options and make sure the UID/GID match on both sides — permissions on a mounted drive are ultimately enforced by the remote server, not your local commands.
Case 4: SELinux denying access even though permissions look correct
On SELinux-enforcing distros (Rocky, Alma, CentOS) a file can have perfectly correct chmod/chown and still throw "Permission denied" because of its SELinux security context. Check with ls -Z and restore the expected context with restorecon -Rv /path instead of disabling SELinux outright.
How to prevent "Permission denied" errors
- Set ownership and permissions as part of your deploy/install script, not by hand after something breaks.
- Avoid running game/web services as root — a dedicated low-privilege user contains the blast radius of any bug.
- Document the expected owner for each folder so the next admin doesn't guess and reach for 777.
- Use
setfaclfor shared access between two users instead of loosening permissions for everyone. - After moving or restoring files on SELinux systems, run
restoreconrather than disabling SELinux.
Related Linux and access errors
For the SSH-key version of this error, see "Permission denied (publickey)". If a command needs elevated rights, see "user is not in the sudoers file". For broader hardening, see how to secure a Linux VPS, and if a script with correct permissions still won't run on schedule, check cron job not running.