Fix "Permission denied" on Linux (chmod & chown Explained)
bash: ./start.sh: Permission deniedPermission denied (publickey)"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.
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 ^groupCase 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.
Managed servers, no Linux required
Prefer not to touch the command line? Our managed game hosting handles permissions, updates and security for you.
Frequently asked questions
What does chmod +x do?
It adds the "execute" permission to a file, letting you run it as a program or script (./file). Without it, Linux refuses to execute the file even if you own it.
When should I use chown instead of chmod?
Use chown when the file is owned by the wrong user — for example a service running as one user can't write files owned by root. chmod changes what actions are allowed; chown changes who owns the file.
Is chmod 777 safe?
No. 777 lets any user on the system read, write and execute the file. It's almost never the right fix and is a real security risk. Fix ownership with chown and use 755/644 instead.
Why does chmod 777 sometimes not even fix "Permission denied"?
Because the real block is often SELinux context or a network-mount permission model, neither of which chmod controls. Check ls -Z (SELinux) or your mount options (NFS) instead of loosening permissions further.
What's the difference between "Permission denied" and "Permission denied (publickey)"?
Plain "Permission denied" is a filesystem permission problem on a file or folder. "Permission denied (publickey)" is specifically SSH rejecting your key during login — a completely different, authentication-level issue.
Can a full disk cause a "Permission denied"-style error?
Not directly — a full disk usually gives "No space left on device" instead. But some apps mask that as a generic write failure, so if permissions look correct, also check disk space with df -h.
How do I check if SELinux is the cause of a permission error?
Run ls -Z on the file to see its SELinux context, and check /var/log/audit/audit.log for "denied" entries. If SELinux is blocking it, restorecon -Rv on the path usually fixes it without disabling SELinux.
Related articles
Fix SSH "Connection refused" / "Connection timed out"
SSH "connection refused" vs "timed out" — what each means and the exact steps to fix them.
Read fix Linux & VPSHow to Check CPU, RAM & Disk Usage on a Linux Server
The essential commands to check CPU, RAM and disk on Linux — and find what's eating them.
Read fix Linux & VPSEssential Linux Commands for Game Server Admins
A practical Linux cheat sheet for running a game server on a VPS — files, processes, screen, services and logs.
Read fix
