Game server file permissions and ownership

A game server runs as one ordinary user, and it can only read, write or run the files that the Linux permissions on them allow that user to. Almost every "Permission denied" on a game server comes from one of three things: a file created by a different user (typically root, on a machine you run yourself), a script or binary missing its executable bit after an upload, or a file someone made read-only on purpose and forgot about. On a panel the ownership side is mostly handled for you - everything in a server's folder belongs to the same user the server runs as - so the problems that remain are modes and the second, separate layer of permissions: which of your staff the panel lets touch which files.

This post covers both layers: what the letters in ls -l mean, how to fix ownership and modes, when making a config read-only is a good idea, the errors each mistake produces, and how to give a moderator file access without giving them the keys to everything.

Two layers of permission#

It helps to keep them apart, because they fail differently.

1. Linux file permissions decide what the game process can do to a file. If they are wrong, the game fails - it cannot save, cannot load a plugin, cannot start.
2. Panel permissions decide what a person can do through the panel's file manager and SFTP. If they are wrong, a person is blocked - or, worse, is not blocked when they should be.

A file can be perfectly readable by the game and completely hidden from a moderator, or editable by the moderator and unreadable by the game. When something is denied, the first question is which layer said no: an error in the game's console is the first layer, an error in the file manager or SFTP client is usually the second.

Reading Linux permissions#

Every file and folder has an owner, a group and a mode. ls -l shows all three:

-rw-r--r-- 1 steam steam   1843 Oct  6 21:14 server.properties-rwxr-xr-x 1 steam steam    412 Oct  6 21:10 start.shdrwxr-xr-x 5 steam steam   4096 Oct  6 21:20 world-rw------- 1 root  root     96  Oct  6 20:55 token.txt

The first ten characters are the type and the mode. The first character is - for a file or d for a directory. The next nine are three groups of three: what the owner may do, what members of the group may do, and what everyone else may do. In each group, r is read, w is write and x is execute.

For directories the letters mean something slightly different, and this trips people up:

A directory without x cannot be entered even if every file inside is readable. A directory without w prevents deleting a file inside it, even if the file itself is writable. Games that write a save by creating a new file and renaming it over the old one need w on the directory, not just on the save.

The modes are often written as three octal digits, one per group, adding 4 for read, 2 for write and 1 for execute:

New files get their mode from the creating process's umask, usually 022, which produces 644 for files and 755 for directories.

Ownership: the root trap#

On a machine you run yourself - a VDS, a home server - the most common permissions problem is a server that runs as an unprivileged user (say steam) and a folder full of files created by root. It happens like this: you install the game as steam, then one evening run an update or unpack a mod as root with sudo. Those new files belong to root, mode 644, and steam can read them but not change them. The server starts, runs, and fails the first time it tries to save, update a config or rewrite a mod's data file.

The fix is to hand the tree back to the service user, then stop running things as root in it:

# give the whole server folder back to the user it runs as$ sudo chown -R steam:steam /srv/valheim# run updates and edits as that user from now on$ sudo -u steam /home/steam/steamcmd/steamcmd.sh +runscript update.txt

Running the game itself as root "to avoid permission problems" is the wrong fix. A plugin with a vulnerability, or a malicious mod, then has full control of the machine instead of one folder. Multiple game servers on one VDS covers running each server as its own user, which also stops one server's files being reachable from another.

Ownership on a panel#

On a Pterodactyl-based panel this whole category mostly disappears. The daemon runs every server's container as a single unprivileged system user, and the server's folder - including everything you upload through the file manager or SFTP - belongs to that user. Nothing you can do through the panel creates a root-owned file in your server's folder, so the root trap does not happen.

You also cannot change ownership. chown needs root, there is no root inside the container, and an SFTP client's "change owner" option will fail with Operation not permitted. That is by design: the container's isolation depends on it. If ownership looks wrong in a listing, it is usually the SFTP client displaying a numeric user id it has no name for, not a real problem. How containers and the daemon fit together is explained in Pterodactyl panel explained.

What you can still get wrong on a panel is the mode.

The executable bit#

A shell script or a native binary needs x to run. When it is missing, the error is blunt:

/home/container/start.sh: Permission deniedbash: ./RustDedicated: Permission denied

The usual causes:

• The file was uploaded through a browser. HTTP uploads carry contents, not permissions, so every uploaded file arrives as 644.
• It came from a zip made on Windows. Windows has no executable bit, so zip files created there do not record one. A .tar.gz made on Linux keeps modes; a Windows zip does not.
• It was edited and saved by a tool that rewrote it rather than editing in place.

The fix is chmod +x on the file, or setting the mode to 755. With a shell, that is chmod +x start.sh. On a panel, use the permissions option in the file's menu in the file manager where your panel offers one, or the Properties dialog in an SFTP client such as WinSCP or FileZilla, which can set the mode directly. SFTP and the file manager covers the clients.

A related error looks like a permissions problem and is not:

/bin/sh^M: bad interpreter: No such file or directory

The ^M is a Windows line ending. The script was saved with CRLF line endings, and Linux reads the carriage return as part of the interpreter's name. Convert it to LF line endings in your editor (most have a setting at the bottom of the window), or with dos2unix on your own machine. No change of mode fixes it.

Read-only configs: when the game keeps undoing your edits#

The most common complaint about game server configs is not "Permission denied" but the opposite: "I changed a setting and the game changed it back." Nearly always, the game rewrote the file from its in-memory copy.

Several games do this:

• Minecraft rewrites server.properties on startup, adding any missing keys with their defaults and dropping your comments. Edit it with the server stopped and keep notes about why a value is set somewhere else.
• Project Zomboid rewrites the server's .ini on startup and when settings are changed in-game.
• Unreal Engine games often write their Saved/Config files on shutdown, so an edit made while the server runs is replaced with whatever was in memory when it stopped.

The correct fix in every case is to stop the server, edit, then start it. That is boring and it always works.

Making the file read-only with chmod 444 is the other option, and it is a hack worth knowing the limits of. It does stop the game from rewriting the file. But some games log an error every time they try to save it, some refuse to start when they cannot write a config, and you will forget it is read-only in six months, edit it, and wonder why the editor will not save. A SteamCMD validate will not help either, because it only restores files the game ships, not the ones it generates. If you use the trick, write it down in the file itself (# read-only on purpose, see admin notes) and only for a file the game is known to tolerate being unwritable.

Errors and what they mean#

Read-only file system deserves a note. It is not about any one file's mode: the operating system has mounted the whole volume read-only, often after detecting a disk error. You cannot fix it from inside the server, and it should go to your host as a ticket at once.

Panel permissions: who can touch which files#

The second layer matters as soon as more than one person runs the server. A Pterodactyl-style panel lets the owner add subusers and give each a set of permissions, and the file-related ones are usually split finely - in upstream Pterodactyl they include separate permissions to read files, read file contents, create, update, delete, archive and use SFTP. RE:NODE builds on this with roles, teams and grants: a role holds permissions, a team holds people, and a grant joins a team to a server, with time-boxed access and an activity log per server.

How that maps to real staff:

Two things are worth getting right. First, file access is close to total access: anyone who can edit files can edit the admin list, install a plugin, or read the token in a config. Grant it as carefully as you would grant console access. Second, SFTP access is its own permission because it is the most powerful way to use the others - a whole folder can be downloaded or replaced in seconds. Subusers and least privilege covers designing the roles, and game server admin account security covers the accounts behind them.

Files that should not be readable at all#

Some files on a game server are secrets: the Steam game server token in a startup line or config, a FiveM licence key in server.cfg, a database password in a plugin's config, an RCON password. On a machine you run yourself, give them mode 600 so only the service user can read them. On a panel, the important control is the second layer: who has file read access at all. Remember too that secrets end up in places you did not put them - startup lines echoed into logs, backups that include configs, screenshots of the file manager shared in Discord. Environment variables and secrets and RCON safely cover the habits that keep them where they belong.

FAQ#

Why does my game server say Permission denied when it starts?

Usually a start script or binary has lost its executable bit, often after being uploaded through a browser or unpacked from a Windows zip. Set the file's mode to 755 in your SFTP client or the file manager. If the message names a data file instead, the server's user cannot write to it or its folder.

Should I just chmod 777 everything?

No. It makes every file writable by every user on the system, which on a shared machine or a compromised plugin is a gift. It also rarely fixes the real problem, which is usually ownership or a single missing executable bit.

Why does my config file keep resetting?

The game rewrote it from memory, either on startup or on shutdown. Stop the server, make the edit, then start it again. Making the file read-only works for some games but causes errors in others.

Can I change file ownership on a panel server?

No, and you do not need to. Every file in the server's folder belongs to the user the server runs as, and changing ownership needs root, which a container does not have.

Can I give someone access to only one folder?

Most panels grant file permissions per server rather than per folder. If someone should only touch one plugin's config, the safest options are making the edit for them, or giving them a test server where full access does no harm.