Project Zomboid Server Save Location: Find the Active World

To find the active Project Zomboid server save location, trace the dedicated-server process that is running now. Confirm its operating-system account, home directory, launch profile and startup log, then match those clues to the multiplayer world directory. This avoids mistaking an old copy, a second server profile or installed program files for the data the live server uses.

This walkthrough is limited to Linux dedicated servers. The example was tested on one isolated Docker server running Project Zomboid Build 42.20.4, version 42.20.4 b0bbce05d5. It verifies where that server created a named world and that the directory remained after one clean restart. It does not prove player progress, cover Windows or Host mode, or describe a provider panel. Treat the paths below as evidence from this test, not universal defaults.

Find the process that actually runs the server#

Begin with the running game process, not a search for a familiar folder name. A machine may contain multiple installations, test profiles or old world copies. The active process tells you which account and command line to investigate.

On a Linux host, an administrator can list processes and their owners with a read-only command such as:

ps -eo user,uid,gid,pid,args | grep '[P]rojectZomboid'

If the server runs in a container, inspect the processes inside that container or use the container runtime’s process listing. The process owner may be a service account such as steam, rather than your interactive login user. Record the username, UID/GID and process ID. If there is more than one game process, identify which unit or container is the service your players use before following any path.

Record the version and branch reported by the running server’s startup log as well. During the test, the log identified Build 42.20.4 b0bbce05d5. The official site listed 42.20.4 as Stable when this guide was checked; the newer 42.21 announcement describes an Unstable build and recommends a manual backup before trying it. A path check does not establish that a world can be moved between builds or branches. Keep the server and intended clients on a supported matching build, and consult the official 42.21 announcement before changing branches.

Check the process account and data root#

After identifying the process, inspect that process’s environment and working directory. On Linux, /proc/PID exposes information for a specific running process. Replace PID below with the process ID you just verified:

tr '\0' '\n' < /proc/PID/environ | grep -E '^(HOME|USER)='
readlink -f /proc/PID/cwd

Permission rules may prevent reading another user’s process details. Ask the administrator who owns the service to run the inspection, or use the deployment’s supported read-only process tools. Do not guess the service home from your own shell’s $HOME.

Also inspect the service definition or container configuration for an explicit data-directory option or mounted volume. A command-line override and a bind mount can place mutable data outside the process’s home. In a container, distinguish the path visible inside the container from the host path mounted into it. You need to identify the source that persists when the container is replaced; an image’s writable layer may not be durable.

The test process ran as UID/GID 1000 (steam) with HOME at /home/steam. It used the executable in /home/steam/pz-dedicated, and its command included -servername d02probe with no -cachedir override. Those observations led to generated data under /home/steam/Zomboid/. Your service may use a different account, home, mount or explicit override, so verify each part on your own system.

Separate installed files from mutable server data#

The dedicated-server installation contains program files used to run the game. The active save belongs to the server’s data directory. These locations can be siblings, mounted separately or managed by a container, so finding an executable does not by itself reveal where the world is stored.

In the test, the executable lived under /home/steam/pz-dedicated, while generated server profile files appeared under /home/steam/Zomboid/Server/. The multiplayer world appeared under /home/steam/Zomboid/Saves/Multiplayer/. That separation is useful when locating files: follow the live process and its data root, rather than treating the installation directory as the save directory.

The account that owns these files matters too. The test’s generated profile and world data were owned by steam:steam. If a path is unreadable from your account, that does not mean the server has no save. Ask the service administrator to inspect it or use the access method they provide; avoid changing permissions just to make a search command work.

Match the launch profile to the world name#

Look at the server’s actual start command or service configuration for -servername. The value selects the profile name used by a dedicated server. In the test, the command line included -servername d02probe, and the server generated a matching d02probe.ini profile. Its world directory used the same name.

This is why servertest is not a safe assumption: a server can be started with another profile. Match the argument for the process you already identified with the profile file generated under that process’s account. For details on finding and verifying the active INI, see how to edit and verify Project Zomboid server INI changes. That guide covers configuration edits; this one uses the profile name only to locate the corresponding world.

Do not edit or rename a profile while you are trying to identify it. If the command, INI filename and world directory disagree, pause and check whether you are looking at a second process, another service account or a different data mount. A matching name is a useful clue, but it should agree with the startup log and the server instance you meant to inspect.

Corroborate the multiplayer world directory#

In the tested container, the named world directory was:

/home/steam/Zomboid/Saves/Multiplayer/d02probe/

Its contents included map_t.bin, world-dictionary metadata, vehicles.db and players.db. These files helped confirm that the directory contained generated server-world data. Their presence does not, by itself, prove when a player last joined, which character was saved, or that every file is current. This test did not connect a client.

Use read-only listing and metadata checks to compare the candidate directory with the process clues:

ls -ld -- /path/to/Zomboid/Saves/Multiplayer/NAME
find /path/to/Zomboid/Saves/Multiplayer/NAME -maxdepth 1 -type f -printf '%f\t%u:%g\t%s bytes\t%TY-%Tm-%Td %TH:%TM\n' | sort

Replace NAME with the profile established from the live process. These commands list top-level files, owners, sizes and modification times; they do not establish that the server is actively writing to the directory. Run them with enough permission to read the service data, and avoid publishing logs or file listings that expose player identifiers or private server details.

Verify a restart only when it is safe#

The test was deliberately isolated. After its first startup created d02probe, the server received SIGTERM. Its log showed Shutdown handling started, a SaveAll operation, player and world-data saving, and Shutdown handling finished; the container exited with code 0. The same container was started again. It reported Build 42.20.4 b0bbce05d5, checked the existing map_t.bin, and reached *** SERVER STARTED ****. The d02probe directory and its metadata remained in place.

That is evidence for one clean stop/restart on this Linux Docker setup. It is not a reason to restart a live community server just to test a path. If you have an approved maintenance window, follow your installation’s documented stop/start procedure and check that the same profile and data mount are used after startup. Otherwise, rely on the process, command line, log and matching directory observations you can make safely. Don’t send a kill signal or modify live files as a shortcut.

If the post-restart process now points to a different account, home, profile or mount, stop and reconcile the difference before treating either directory as active. A server that starts successfully against an empty destination can still be using a different world than expected. Diagnosing that migration outcome requires a separate comparison of the source and destination; locating the old folder alone does not show how to restore it.

Keep the conclusion within the evidence#

The tested Project Zomboid server save location followed a specific chain: process owner steam, home /home/steam, profile d02probe, startup log reporting Build 42.20.4 and the matching directory under Zomboid/Saves/Multiplayer/. The world directory survived one graceful restart of that same isolated container. Use the same chain on your own host, replacing every example path with what its live service actually reports.

This procedure covers Linux dedicated servers only. It does not document Windows defaults, in-game Host saves, other service managers, hosting-panel paths, game-client progress or conversion between incompatible saves. The Project Zomboid hosting page is available if you prefer to ask about managed server file access; confirm current availability and the actual file access offered before choosing a service.