A frequent issue encountered by Valheim dedicated server administrators is sudden world rollbacks: players spend hours gathering resources and constructing bases, only to find that after a VPS reboot or scheduled daemon restart, recent structures vanish and the world reverts to day one or an older state.
In this guide, we investigate how Valheim handles state persistence, prevent premature process termination via SIGKILL, correct filesystem permissions for .db and .fwl binaries, and resolve startup argument naming mismatches.
Why Valheim Servers Fail to Persist World State: Root Causes#
Progress loss on a Valheim dedicated server typically originates from one of four technical failure points:
- Premature Process Termination (SIGKILL): Valheim serializes memory objects (zDOs) into disk storage during shutdown. If your service manager (systemd or Docker) issues a kill signal before disk serialization completes, progress accumulated since the previous autosave is lost.
- Filesystem Permission Denials: The daemon runs under an unprivileged user (such as
steam), while the world directory is owned byroot. - World Argument Mismatch: If the
-worldparameter in your startup script does not match the exact case-sensitive filename on disk, the engine generates an empty seed world. - Storage Space Depletion: Valheim writes to a staging file before atomically renaming to
.db. If disk partitions reach 100% capacity, the write pipeline fails.
Verifying Permissions and Save Directory Structure#
On Linux, the Valheim dedicated server persists world databases within ~/.config/unity3d/IronGate/Valheim/worlds_local/.
Inspect existing world files and directory ownership:
ls -la ~/.config/unity3d/IronGate/Valheim/worlds_local/
If directory ownership is set to root, the service user cannot flush in-memory structures during save intervals. Reassign ownership to the dedicated service account:
sudo chown -R steam:steam ~/.config/unity3d/IronGate/Valheim
sudo chmod -R 755 ~/.config/unity3d/IronGate/Valheim
Configuring Graceful Service Shutdown via SIGINT#
Default systemd configurations send SIGTERM followed by a hard SIGKILL after 10–15 seconds. High-concurrency Valheim worlds containing extensive building structures require 60 to 90 seconds to flush all zDO data to disk.
Open your service definition at /etc/systemd/system/valheim.service and configure graceful shutdown parameters:
[Unit]
Description=Valheim Dedicated Server
After=network.target
[Service]
Type=simple
User=steam
Group=steam
ExecStart=/opt/valheim/start_server.sh
KillSignal=SIGINT
TimeoutStopSec=120
Restart=on-failure
RestartSec=10s
[Install]
WantedBy=multi-user.target
The KillSignal=SIGINT parameter instructs the Unity game engine to execute a controlled world commit, while TimeoutStopSec=120 grants the process two full minutes to complete disk writes.
Reload systemd and restart the service:
sudo systemctl daemon-reload && sudo systemctl restart valheim
Validating World Target Parameters and Auditing Player.log#
Inspect the execution flags defined in your start_server.sh script:
grep -E "valheim_server|-world" /opt/valheim/start_server.sh
Ensure the -world "Dedicated" argument matches the exact case of Dedicated.db and Dedicated.fwl within worlds_local/ (on Linux filesystems, dedicated and Dedicated represent distinct files).
To verify that periodic saves are executing successfully, audit the application runtime log:
tail -n 50 ~/.config/unity3d/IronGate/Valheim/Player.log | grep -i "world saved"
Entries confirming World saved ( 842.12ms ) verify that the engine is writing snapshot updates to disk as expected.
If you are looking for dedicated Valheim hosting featuring automated graceful shutdown routines, pre-restart cloud snapshots, and intuitive server controls, high-performance Valheim dedicated server hosting manages database persistence and hardware reliability automatically.
