Linux Basics for Game Server Owners

You rented a machine. It arrived as an IP address, a username, a password and no interface. Everything you know about computers involves a window and a mouse, and neither is available.

The good news is that running a game server needs a small subset of Linux. About a dozen commands cover nearly everything, and the rest can be looked up when you meet it. The bad news is that four specific mistakes will cost you the machine, and all four are easy to make in the first week.

Getting in

You connect over SSH. On Windows, PowerShell or Windows Terminal has it built in; on macOS and Linux it is in the terminal already.

ssh username@your.server.ip

You get a prompt. That is the whole interface.

Use a key, not a password. SSH keys are a pair of files: a public one you put on the server and a private one you keep. Once set up, you log in without typing a password, and, much more importantly: nobody can guess their way in.

This matters more than it sounds. A server exposed to the internet with password login enabled receives automated login attempts continuously, from the day it exists. Not because anyone is targeting you; because everything is scanned constantly. Game server security covers the rest, and keys are the first item on the list.

Never log in as root for day-to-day work. Create a normal user, give it sudo rights, and use that. Root can delete anything without asking, and the whole point is that you should have to ask.

The dozen commands

Moving around

• pwd, where am I
• ls -la — what is here, including hidden files and permissions
• cd /path; go somewhere; cd.. goes up

Looking at files

• cat file, print the whole thing
• less file: page through it; q to quit, /word to search
• tail -f file — watch a file as it grows. The single most useful command for a server owner, because it is how you watch a log live.
• grep "error" file, find lines containing something

Doing things to files

• cp source dest, mv source dest, rm file
• mkdir name
• nano file; a text editor that is usable without instructions. Ctrl-O saves, Ctrl-X exits.

Seeing what is running

• htop, processes, CPU, memory, interactively. Install it first thing.
• df -h — disk space
• free -h: memory

Permissions

• chown user:group file, who owns it
• chmod 644 file; who may read and write it

That is most of it. Everything else you will look up once and then remember or look up again.

The four mistakes

1. rm -rf with a typo. This deletes recursively without confirmation. A space in the wrong place — rm -rf / home/user/thing rather than rm -rf /home/user/thing, attempts to delete the entire filesystem.

Habits that prevent it: type the path first and the command second, never run it as root unless you have read the line twice, and prefer mv to a trash directory over rm for anything you might want back.

1. Running the game server as root. If the server process is compromised: through a plugin, a bad upload, an exploit, whatever compromised it now owns the machine. Run it as its own unprivileged user with access to nothing but its own directory.

This also causes a subtler problem: files created by root cannot be written by a non-root process later, which produces permission errors that look like something else entirely.

3. Editing a config with the wrong tool. A file saved with Windows line endings can break a shell script or a config parser in ways that produce baffling errors. If you edit on Windows and upload, check for this. Editing directly with nano avoids the whole category.

1. Leaving everything open. A fresh machine typically has a firewall that permits everything. Every port your software listens on is reachable from the entire internet, including the database you assumed was internal. Security basics is the fuller treatment; the summary is to close everything and open only what you need.

Permissions, briefly

Every file has an owner, a group, and three sets of permissions: read, write, execute — for the owner, the group, and everyone else.

chmod 644 means owner can read and write, everyone else can read. chmod 755 adds execute, which is what a program or a directory needs. chmod 600 means only the owner can read it at all, which is what a private key or a file containing a password should be.

The single rule that prevents most problems: the game server's files should be owned by the game server's user. If you upload files as root and then run the server as gameserver, it cannot write its own logs, its own saves, or its own cache, and the failure is usually silent.

Keeping it running

Closing your SSH session kills anything you started in it. That is the first surprise everyone meets.

Three answers, covered properly in keeping a game server running: screen and tmux keep a session alive that you can reattach to, and systemd runs the server as a managed service that starts on boot and restarts on crash.

For anything you care about, the answer is systemd. For a quick test, screen is fine.

Updates

apt update && apt upgrade on Debian and Ubuntu; dnf upgrade on Fedora and its relatives.

Do this regularly. Unpatched systems are the second most common way machines are compromised, after weak passwords. It takes a minute and it can be scheduled to happen automatically for security patches only, which is the sensible default for a machine you do not want to think about.

Note that this updates the operating system, not your game server, those are separate, and updating the game server without breaking it is its own discipline.

Disk space

df -h shows it. Watch it, because a full disk breaks things in confusing ways: a server that will not save, a database that refuses writes, a log that stops.

The usual culprits are logs that nobody rotates and backups that accumulate forever. Both are solvable in an afternoon and both will otherwise fill a disk eventually, generally at a weekend. Backups covers the retention side.

Getting files onto the machine

You will need to do this constantly — configs, plugins, maps, backups coming back, and there are three reasonable ways.

scp copies a file over the same SSH connection you already use.

scp plugin.jar username@server:/home/gameserver/plugins/

Simple, works everywhere, no setup. Fine for one file at a time.

rsync is the same idea but only transfers what changed, resumes interrupted transfers, and can mirror whole directories.

rsync -avz --progress./plugins/ username@server:/home/gameserver/plugins/

Worth learning the moment you are moving more than a couple of files, and the right tool for pulling backups down.

SFTP with a graphical client; FileZilla, WinSCP, Cyberduck. It uses the same SSH credentials and gives you two file panes and drag-and-drop. There is nothing wrong with this and a lot of experienced people still use it for bulk work.

What not to do: plain FTP. It sends credentials in clear text, it is frequently the thing that gets a server compromised, and SFTP is available on every machine that has SSH.

Ownership after upload. Files you copy in are owned by the user you copied as. If you upload as root and the server runs as gameserver, the server cannot write to them. Fix it as you go:

sudo chown -R gameserver:gameserver /home/gameserver/server

This one line resolves a very large share of "it worked yesterday" problems.

When something goes wrong

Four commands cover most first-response diagnosis.

systemctl status mygame, is it running, and what did it say as it died.

journalctl -u mygame -n 100 — the last hundred lines of its log. Add -f to follow live.

df -h: a full disk causes failures that look like anything else. Check it early; it is free.

htop, is something eating all the memory or pinning a core.

Then read the log from the top rather than the bottom. The last error is usually a consequence of the first one, and people routinely spend an hour on a symptom. Reading game server logs covers doing this properly, and diagnosing a crash covers the method when the answer is not obvious.

Where to go next

Once the basics are comfortable, the things worth learning in order are: running the server as a systemd service, closing the ports you are not using, reading your logs, and automating restarts.

Everything else can wait until you need it.

And if all of this sounds like more than you want to take on, that is a legitimate conclusion; managed hosting exists precisely for it, and dedicated versus VPS versus managed covers the trade. You pay more and you learn less, and for a lot of people that is the correct choice.