Palworld Dedicated Server (2394010)

[FMAWrath2069]

Compatibility Report

• Name of the game with compatibility issues:
• Steam AppID of the game: 2394010 (Possibly 1623730 As Well)

System Information

• GPU: None (Server)
• Video driver version: N/A
• Kernel version: 6.17.0-14-generic
• Link to full system information report as Gist: https://gist.github.com/FMAWrath2069/41a80f280778a8a02766b141f5c299ed
• Proton version: 11 (Testing this version tomorrow but bug is present in Wine 11 and its 3am so I need sleep)

I confirm:

• [X ] that I haven't found an existing compatibility report for this game.
• [X ] that I have checked whether there are updates for my system available.

Symptoms

When Palworld is launched within Wine or Proton a race condition happens where Wine or Proton is reading files and causes Palworld to not be able to update files during a save. When this happens the server will lock down and disconnect all players. Upon attempting to rejoin players will be met with a Connection Timeout Error. To restore connectivity the server must be restarted.

Reproduction

Any server that is ran through Wine or Proton has the possibility to have this happen. Some are lucky and do not have it happen for a long time but others it will crash immediately after the first save. To expedite troubleshooting I set the server to autosave at 5s intervals. Typically this will cause any server to crash within a couple minutes.

It is as simple as turning the server on and waiting.

I will be including more logs after I sleep and get additional testing done.

[devmauvsantos]

Getting the same issue, here is my report so far:

Environment

• Palworld Dedicated Server (Steam AppID 2394010), build 24088465 / v1.0.0.100427
• GE-Proton10-26 (also reported on GE-Proton9-27 in downstream issue libjpeg-turbo dependency for macOS #2)
• Host: Ubuntu 24.04, ext4, Docker 29.x, running the Windows server binary via proton run (native Linux binary is unaffected)
• Reproduces with mods disabled, fresh worlds, and migrated worlds; not memory/permissions-related

Symptom

On a dedicated server, saves alternate deterministically: every other RCON Save fails to commit. A failed save writes all temp data but never finalizes; a connected player is hard-disconnected within ~3s of the wedge; a joining client black-screens because the world thread is blocked.

Root cause (traced via inotify + strace on the game process)

Palworld 1.0 uses a staged atomic save:

1. Writes staging dirs world_save_temp/ and world_save_bak/, plus Level.sav.new_tmp, LevelMeta.sav.new_tmp, Players/*.sav.new_tmp.
2. Writes a manifest .atomic_save_update_manifest_world.json with "State": "Prepared" listing each file + ExpectedSize.
3. Should then verify sizes and rename each .new_tmp → real .sav, and advance the manifest to committed.

On the failing (alternating) saves under Wine:

• All temp files + the "Prepared" manifest are written (confirmed via inotifywait — CREATE + CLOSE_WRITE events present).
• No rename/moved_from/moved_to event ever fires — the final commit rename is never issued. strace on the game process (GameThread, ~40 threads) + wineserver shows zero rename/renameat2/link syscalls on the save files during a failed save.
• The manifest stays "State": "Prepared" indefinitely; orphaned .new_tmp files accumulate.
• The game thread appears to block waiting for a commit signal that never arrives.

This is not a rename() syscall failure — the rename is never called. The game's atomic-save state machine does not advance from "Prepared" to commit. This strongly implicates Wine's async I/O completion delivery (IOCP / overlapped I/O completion) or a file flush/verify-completion signal that Wine delivers unreliably on alternating attempts — the game waits on that signal before issuing the rename.

Ruled out (does not fix it)

• PROTON_NO_ESYNC=1 + PROTON_NO_FSYNC=1 — no change
• Filesystem: ext4 bind mount AND tmpfs both fail identically
• Pre-cleaning orphaned .new_tmp between saves — no change (state is internal, not on-disk)
• Disabling engine autosave (AutoSaveSpan=86400) — no change
• Raising ConnectionTimeout to 180s — player still hard-disconnects in ~3s (not a timeout)

Reproduction

1. Run the Windows Palworld dedicated server binary under GE-Proton on Linux.
2. Issue RCON Save repeatedly (~15s apart), or set autosave to a short interval.
3. Observe: every other save leaves orphaned Level.sav.new_tmp + a "State":"Prepared" manifest; Level.sav mtime does not advance; connected players get disconnected on the failing saves.

Impact

Player inventory/progress is persisted via Palworld's save path; under Proton this path is ~50% broken, so in-game progress does not reliably persist. Makes the Windows-binary-under-Proton dedicated server unusable for real play. Native Windows saves this exact world every 30s with no issue.