Linux for FiveM Servers: systemd, Permissions, Key Commands

Most cities don't die from bad Lua — they die because nobody on staff knows what to type when the box misbehaves at 3 a.m. If you run a fivem linux server, the terminal is your admin panel, and a dozen commands separate "we were back up in four minutes" from "we waited nine hours for the host's support queue." This is the Linux literacy every owner needs: not a one-time install tutorial, but the daily operating knowledge — systemd, permissions, logs — that keeps a live city standing.

Why Most Serious FiveM Servers Run on Linux

Three reasons, and none of them are ideology. First, cost: a Linux VPS skips the Windows Server license, which on rented hardware typically saves €10–25 a month for identical specs. Second, headless stability: no desktop session eating 1–2 GB of RAM, no GUI updates forcing reboots — a Debian or Ubuntu box will happily sit at 200+ days of uptime. Third, Cfx.re ships native Linux artifacts (fx.tar.xz from the build_proot_linux channel), so there's no Wine layer and no second-class support anymore.

The catch is the learning curve. There's no desktop to click around. That's the rest of this guide.

The Mental Model: You Rented a Computer, and SSH Is Your Keyboard

Strip the mystique away: a VPS is a computer in someone else's building. SSH is not "hacker stuff" — it's plugging a keyboard into that computer from your bedroom.

ssh [email protected]

Everything after that prompt is just typing at that machine. When you run ls, you're asking it what files it has. When you run systemctl restart fivem, you're pressing its restart button. Nothing you type in a terminal is more magical than clicking a button in a panel — it's the same actions with the labels removed. Once that clicks, the fear goes away and the speed shows up.

Run the Server Under systemd, Not a Detached Terminal

The classic beginner move is starting run.sh inside a detached screen or tmux session. It works until the box reboots for a kernel update at 4 a.m. and your city simply never comes back. systemd fixes both failure modes: it starts the server at boot and restarts it when the process dies.

Create /etc/systemd/system/fivem.service:

[Unit]
Description=FiveM server
After=network-online.target mariadb.service
Wants=network-online.target

[Service]
User=fivem
Group=fivem
WorkingDirectory=/home/fivem/server-data
ExecStart=/home/fivem/artifacts/current/run.sh +exec server.cfg
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Restart=on-failure with RestartSec=10 means a crashed FXServer is back within ten seconds without a human touching anything. If you launch through txAdmin, set ExecStart to run.sh with no arguments and let txAdmin load the config.

sudo systemctl daemon-reload
sudo systemctl enable --now fivem
systemctl status fivem

enable --now registers it for boot and starts it immediately. Run daemon-reload any time you edit the unit file, or systemd keeps using the old copy.

tmux still has a job: attaching to a live console while you debug. But it's a debugging tool, not a process manager. The process manager is systemd.

Make a Dedicated fivem User — Root Is a Liability

Every resource on your server executes with the permissions of whatever user runs FXServer. Run it as root and a single malicious or backdoored script — including things hidden inside escrow-dumped "leaks" — owns the entire machine: your database, your SSH keys, everything. As a locked-down fivem user, the blast radius is one home directory.

sudo adduser --disabled-password --gecos "" fivem
sudo mkdir -p /home/fivem/artifacts /home/fivem/server-data
sudo chown -R fivem:fivem /home/fivem
sudo chmod -R u=rwX,g=rX,o= /home/fivem/server-data

chown sets who owns the files; chmod sets what they're allowed to do. The capital X there is a small trick worth knowing: it marks directories executable (so they can be entered) without marking every script file executable. To work as that user, sudo -iu fivem — and resist the reflex of chmod -R 777 when something errors. That "fix" hands write access to every process on the box; the real fix is almost always a chown back to fivem:fivem after uploading files as root.

The 15 Commands That Cover 90% of Day-to-Day Ops

You don't need to "learn Linux." You need these:

cd / ls -lah — move around, list files with sizes and owners
cp / mv — copy, move or rename
nano file — quick edits (server.cfg tweaks) without leaving SSH
less file — read a big file page by page; q quits
tail -f file.log — watch a log live as lines arrive
grep -i "text" file — find lines matching text, case-insensitive
df -h — disk space per mount (full disks kill MySQL first)
du -sh /home/fivem/server-data/* — what's actually eating the disk
htop — live CPU/RAM per process (sudo apt install htop)
systemctl status fivem — is it running, since when, last log lines
systemctl restart fivem — the restart button
journalctl -u fivem -f — the live server console under systemd
unzip pack.zip -d resources/[local]/ — extract straight to the right place
rsync -avP src/ dest/ — copy that resumes and shows progress
scp file fivem@host:/path/ — one-file quick transfer

Two combinations do most of the diagnostic work. Searching today's console for errors:

journalctl -u fivem --since today | grep -i "error"

And finding which resource actually registers some event you're chasing:

grep -Rni "esx:setJob" /home/fivem/server-data/resources/

That second one — recursive grep across resources/ — replaces an hour of opening files in a panel editor with two seconds of typing.

Reading a Crash Out of the Logs

When the server dies, the story is in the journal. Pull the last few hundred lines and read upward from the death:

journalctl -u fivem -n 300 --no-pager

The lines immediately before the crash usually name the guilty party — the last resource that printed, a script error spam loop, or a hitch warning storm. If the journal just stops with no error at all, check whether the kernel killed it for eating all the RAM:

journalctl -k | grep -i "out of memory"

An OOM kill isn't a FiveM bug; it's your box being too small for your resource list. FXServer also writes minidumps on Linux — look in artifacts/current/alpine/opt/cfx-server/crashes/ for .dmp files. You can't do much with a minidump yourself, but attaching it to a Cfx.re forum report is the difference between "it crashes sometimes" and a fixable ticket. For your own debugging, the journal context around the crash is worth more than the dump.

Update Artifacts With a Symlink, Roll Back in Seconds

Never extract a new artifact over the old one. Keep each build in its own directory and point a current symlink at the live one — the same pattern the systemd unit above already uses:

cd /home/fivem/artifacts
mkdir 17346 && cd 17346
wget "https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/<build-url>/fx.tar.xz"
tar xf fx.tar.xz && rm fx.tar.xz
cd .. && ln -sfn 17346 current
sudo systemctl restart fivem

Each build directory holds its own run.sh and alpine/ tree, fully self-contained. If the new build breaks something — it happens; that's why "latest recommended" and "latest" are separate channels — rollback is one command: ln -sfn 17285 current and a restart. Note the -n flag on ln: without it, linking against an existing symlink-to-directory quietly creates the new link inside the old target instead of replacing it, and you restart into the old build wondering why nothing changed.

Moving Files, Opening the Port, and When a Panel Is the Right Call

Web file managers are fine for a 2 KB config edit. For a 3 GB EUP pack they're misery: uploads stall at 80% and start over. rsync -avP resumes where it stopped and verifies what arrived, which also makes it the right tool for pulling backups down to another machine. For drag-and-drop comfort, point WinSCP or FileZilla at SFTP — it's the same SSH login.

Firewall in one line: sudo ufw allow 30120 (and sudo ufw allow OpenSSH before you enable ufw, or you'll lock yourself out). Hardening SSH itself — keys, no root login — is its own topic and covered elsewhere.

And be honest about whether you want this job at all. A game-panel host makes sense when you run one server, have no appetite for 3 a.m. terminal sessions, and can live without root — no custom system services, no cron, neighbors on shared hardware. The raw-VPS trade is more responsibility for more control and usually less money per slot. Plenty of good cities run on panels; the difference is that a panel owner rents these skills, and a VPS owner has them.

Linux competence compounds across everything else you run. If you're stocking the city itself, scripts-tebex.io carries server-side scripts that behave well under exactly this kind of setup, 0resmon-tebex.io focuses on optimized, low-resmon resources that keep that htop view calm, and febex.io is worth a look for rounding out your asset lineup once the box itself is boringly stable — which is the goal.