How to fix "Permission denied" errors on Linux and game servers

"Permission denied" is Linux telling you that the account running a command is not allowed to do what it asked. It is one of the most common errors for new server owners, and it appears when you upload files, start a program, run a script or connect with SFTP. The fix is nearly always one of a few things: wrong ownership, wrong mode bits, or the wrong user. This guide shows how to tell which.

Read the error carefully

The message usually names the file and the action:

• bash: ./start.sh: Permission denied: you cannot execute the file.
• cat: /etc/shadow: Permission denied: you cannot read it.
• touch: cannot touch 'file': Permission denied: you cannot write to that folder.
• Permission denied (publickey): SSH login problem, covered separately below.

Understand how permissions work

Every file has an owner, a group and permission bits for three audiences: the owner, the group and everyone else. List them with:

ls -l

A line like -rwxr-xr-- 1 alex staff 120 Jan 1 start.sh means:

Part	Meaning
-	A regular file (d for a directory)
rwx	The owner may read, write and execute
r-x	The group may read and execute
r--	Everyone else may only read
alex staff	Owner and group

For directories, x means "may enter", and you need w on a directory to create or delete files inside it.

Fix 1: the file is not executable

If a script gives "Permission denied" when you run it, give it the execute bit:

chmod +x start.sh
./start.sh

Archives extracted on Windows and uploaded can lose this bit. Also check that the file system is not mounted as noexec, which stops anything running from it, such as /tmp on some hardened systems.

Fix 2: wrong owner

Files created as root are not writable by your normal user, and the reverse. Check which user runs your program, then give them the files:

sudo chown -R botuser:botuser /home/botuser/mybot

The -R applies it recursively. Be careful with this command: never run it on / or on system folders. A typical mistake is uploading files as root and starting the app as a normal user.

Fix 3: wrong mode on a folder

Apps often need to write to specific folders, such as uploads or logs:

chmod 755 folder
chmod 775 uploads

Avoid chmod 777. It lets every user on the system change the file, which is a security risk, and it hides the real problem. Set the correct owner instead.

Fix 4: a web server cannot read your files

nginx runs as www-data. It needs x on every directory leading to your site and r on the files. A common cause is a site in a home folder that is not traversable:

namei -l /home/alex/site/index.html

This shows the permissions at each step of the path so you can see where access stops.

Fix 5: you need elevated rights

Some actions need root, such as installing packages or editing /etc. Use sudo:

sudo nano /etc/nginx/nginx.conf

Only use sudo when you must. Running everything as root hides ownership mistakes and creates files you cannot later manage as a normal user. See How to create a non-root sudo user.

A redirect such as sudo echo hi > /etc/file fails because the redirect is done by your shell, not by sudo. Use echo hi | sudo tee /etc/file.

SFTP and file manager uploads

If an upload fails or a file will not save, the target may be owned by a different user, or the file may be in use. Try again with the server stopped, and check the destination path. Connect with SFTP and Use the file manager explain how the panel handles file access.

On a managed game server, you normally cannot change ownership yourself, because the panel manages it. If a file really will not change, open a ticket with the exact path and error.

"Permission denied (publickey)" on SSH

This is a login problem, not a file permission problem, though a related cause exists: SSH refuses keys when your home or .ssh folders are too open. Required modes:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also check you are using the right username and key. The full guide is How to set up SSH key authentication, and general connection help is in Connect to your VPS over SSH.

Docker and mounted volumes

Inside a container, the user ID may differ from the host's. A folder mounted from the host must be writable by the user inside the container. Match the user with user: in your compose file or set ownership on the host to the container's user ID. See Docker Compose basics for small projects.

A quick diagnostic routine

1. Read the full error, noting the path.
2. Run id to see who you are, and ps aux | grep program to see who runs the program.
3. Run ls -ld on the file and each parent directory.
4. Change the owner or mode as needed, using the smallest change that works.
5. Check security modules if everything looks right: look in dmesg or journalctl for AppArmor or SELinux denials.

If you are still unsure, write a clear support request and include the output of ls -l and id.

---

Still stuck? Open a ticket on Discord - run /ticket in any channel, pick a department, and include your Server ID or Invoice ID so we can jump straight in.