Getting the same issue, here is my report so far:
proton run (native Linux binary is unaffected)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.
Palworld 1.0 uses a staged atomic save:
world_save_temp/ and world_save_bak/, plus Level.sav.new_tmp, LevelMeta.sav.new_tmp, Players/*.sav.new_tmp..atomic_save_update_manifest_world.json with "State": "Prepared" listing each file + ExpectedSize..new_tmp → real .sav, and advance the manifest to committed.On the failing (alternating) saves under Wine:
"Prepared" manifest are written (confirmed via inotifywait — CREATE + CLOSE_WRITE events present).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."State": "Prepared" indefinitely; orphaned .new_tmp files accumulate.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.
PROTON_NO_ESYNC=1 + PROTON_NO_FSYNC=1 — no change.new_tmp between saves — no change (state is internal, not on-disk)AutoSaveSpan=86400) — no changeConnectionTimeout to 180s — player still hard-disconnects in ~3s (not a timeout)Save repeatedly (~15s apart), or set autosave to a short interval.Level.sav.new_tmp + a "State":"Prepared" manifest; Level.sav mtime does not advance; connected players get disconnected on the failing saves.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.
ge-proton10-26x1 2026-07ge-proton9-27x1 2026-07PROTON_NO_ESYNC=1`x1 2026-07PROTON_NO_FSYNC=1`x1 2026-07
Compatibility Report
System Information
I confirm:
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.