Project Zomboid Server Mods Not Downloading: Trace Workshop

A Project Zomboid server not downloading mods needs a closer look at the first Workshop item that fails. “Not downloading” can mean the server cannot find the item, the transfer did not complete, or the files arrived but the mod was never enabled. Record the exact item ID and server message before you change anything. This guide traces that transfer safely, then shows how to confirm the server loaded the configured Mod ID. One successful download is not a compatibility guarantee.

Tell a failed download from a mod that is inactive#

Start with the server’s own log, not a player’s loading screen. A player’s client may be downloading its copy while the dedicated server has already failed, or the server may have the files while its configuration does not enable the mod. Those are separate problems with different next steps.

Look for the first explicit Workshop message and note whether it names an item, reports a download state, or says the item was installed. Then check the server’s mod-loading lines. In our isolated Build 42.21.0 test, SteamCMD reported File Not Found for a deliberately nonexistent item ID. With a valid Workshop ID in the server config, the server log then reported that the item was installed and separately logged loading SkillJournal. That shows why “downloaded” and “loaded” are two checks; it does not explain Steam outages or every failed transfer.

If the console is still advancing through startup and has not logged a failed item, use the initializing-server checklist to compare stages and timestamps. If the Workshop files are present but the mod’s behavior or activation is wrong, move to the separate inactive-mod branch. Do not start by deleting the whole Workshop cache: that can remove unrelated files without identifying the failing item.

Match the Workshop ID to the Mod ID#

Project Zomboid uses two different identifiers. WorkshopItems= lists Steam Workshop item IDs for transfer; Mods= lists the mod IDs the game loads. Copying a value into the wrong field can look like a download or activation failure, so compare both against the item’s current author instructions.

The Skill Journal author’s Workshop page gives Workshop ID 3776641628 and Mod ID SkillJournal. Its page says it is standalone with no dependencies and supports multiplayer, and asks server owners to include the Workshop ID in the server configuration. Treat those as the author’s current notes for that item, not a promise that every other mod supports your branch. The item’s mod.info in our test also contained id=SkillJournal; the server log later loaded that name.

For that one example, the relevant generated server settings were:

WorkshopItems=3776641628
Mods=SkillJournal

Use your actual server name and its generated configuration file. If you administer a server through a control panel, use the fields that correspond to Workshop items and enabled mods; do not guess a filesystem path the panel does not expose. Keep the two identifiers separate in your notes: one is for transfer and one is for loading.

Capture the first server-side error#

Ask the operator for the first failure line and a few surrounding lines, plus the server build and branch. Keep the affected Workshop ID, exact error wording, timestamp, and whether a later retry or startup completed. Redact passwords, tokens, public addresses, and player identifiers before sharing a log.

Do not translate a single Steam message into a broad diagnosis. In our isolated test, a deliberately nonexistent ID produced ERROR! Download item 9999999999 failed (File Not Found). That is evidence that this specific ID was unavailable to the test, not evidence of a permission problem or Steam outage. If your own log names a different error, preserve it exactly and follow the matching provider or game-support instructions instead of copying a fix for another message.

If the server has reached its ready state but players still cannot join, switch to the server-failed-to-respond diagnostic path. A Workshop transfer error during startup belongs here; a network timeout after startup is a different symptom. Keeping those branches separate prevents a firewall change from being used to fix an item the server cannot download.

Check item availability, storage, and narrow access#

Before retrying, confirm the Workshop item still opens for the server operator’s account and that the ID was copied correctly. Then check the server volume’s free space and whether the server’s own service account can write to the specific Workshop download location. Ask the host to verify this if you cannot see those details.

Compare the target directory and free space before and after one controlled attempt. A directory timestamp or an existing folder alone does not prove the current item revision arrived. If the volume is full, free space using the provider’s documented cleanup process; do not remove a whole Workshop directory while the server is running. If a permission check fails, ask the operator to repair access only for the required server paths and identity. Do not make the directory world-writable, share Steam credentials, or change ownership across unrelated server data.

Disk and permission checks are diagnostic steps, not conclusions. In the test documented here, the item transfer succeeded and the server loaded its Mod ID; we did not induce or repair a permission failure. The result therefore cannot tell you which account or folder is wrong on another host. A provider with no file or log access must confirm those details for you.

Retry one item through the supported server path#

After the ID and target path check out, retry only the failing item using the server host’s documented Workshop update or restart flow. Keep the current world and other Workshop files untouched. If the host exposes no per-item retry, record the current configuration, ask support to retry the named ID, and compare the resulting log with the original.

1. Record the starting point

   Save the server build and branch, the exact Workshop ID, the first transfer error, and the relevant configuration values. Keep the server’s current files and world unchanged.

2. Retry through the host's supported flow

   Ask the operator to retry only the named Workshop item or use the documented per-item update action. Do not paste an unrelated SteamCMD command into a managed host’s console.

3. Compare the result

   Check the same server log for the same item ID, then check whether the server reports the expected Mod ID loading. If the transfer still fails, retain both log snippets and stop repeating blind restarts.

The bounded test for this guide used a newly installed dedicated server in an isolated volume. SteamCMD failed the nonexistent ID with File Not Found; it then downloaded the author’s valid Skill Journal item to steamapps/workshop/content/108600/3776641628 (1,051,097 bytes). The isolated server was on Build 42.21.0, had no published ports, was marked private with UPnP disabled, and shut down cleanly. This is one item and one controlled path. It is not a test of a hosting provider’s panel, a production save, or a general Steam outage.

Avoid copying an arbitrary SteamCMD command into a managed host’s console. Different providers control the server process, Steam identity, filesystem, and update mechanism differently. If the supported retry still fails, keep the exact ID, error, attempt time, and operator’s result together; repeated blind restarts add noise rather than evidence.

Verify the download and activation separately#

After the retry, look for the server’s confirmation for the same Workshop ID, then look for the expected Mod ID in the mod-loading output. In our 42.21.0 run the server logged Workshop: 3776641628 installed to ... and later loading SkillJournal, followed by SERVER STARTED. We did not connect a client or test the mod in the world, so these lines prove only transfer and server-side loading for this isolated configuration.

If the transfer succeeds but the Mod ID is absent from startup, recheck the Mods= value, the mod’s own directory name, required dependencies, and the server’s current config. If the server reports the Mod ID loading but players see an in-game issue, compare the mod author’s current build and multiplayer notes, then test with a safe copy of the world when a mod change could affect data. A completed download alone is not a reason to add or remove mods on a valuable save.

Build 42.21 is the current Stable release in The Indie Stone’s announcement. The release note does not certify every Workshop item for that build. Check the item’s maintainer notes and dependencies for the exact version you run; if they do not identify your build or server mode, treat compatibility as unconfirmed. A completed download of the wrong revision is a separate problem from a failed transfer.

Send support a small, useful packet#

If the named item still will not download, send the operator or host a compact record instead of a full unfiltered log:

• Server build, branch, operating system, and approximate attempt time with time zone.
• Exact Workshop item ID and corresponding Mod ID, if known.
• The first transfer error and a few surrounding server log lines.
• Whether the item page is available, how much free space remains, and whether the service account can write to the target path, if the host can check.
• The result of one targeted retry and whether the server logged the item as installed and the Mod ID as loading.

Do not include Steam passwords, admin credentials, access tokens, player names, or public IP addresses unless the host specifically needs a redacted diagnostic value through a secure channel. Keep the original server data unchanged while support determines whether the failure is an ID, availability, storage, access, or Steam-side issue.

If routine server administration is the larger burden, Game Hosting’s Project Zomboid service documents panel-managed settings and a Workshop-ID update check. Those tools can make ordinary settings and update checks easier to manage; they cannot make an unavailable item download or certify an unsupported mod.