Why are players asked to create a new character when their .sav file exists in Players/?

If the server process was terminated mid-write (via Docker restart or automated cron reboot), the header property 'save_game_class_name' inside .sav is written as 'None.PalWorldPlayerSaveGame' instead of '/Script/Pal.PalWorldPlayerSaveGame'. The engine's reflection loader cannot recognize the class and treats the player as nonexistent.

Did my players lose their Pals and inventory?

No! Palworld stores player inventory, base Pals, and levels inside Level.sav under CharacterSaveParameterMap. The individual player .sav file merely acts as the client profile anchor. Restoring the header or player file restores complete access.

How can I prevent this from happening again on Linux servers?

Never use SIGKILL (kill -9) on PalServer. Always issue an RCON command 'save' followed by 'shutdown 60', and configure container supervisors with a 60-second stop grace period.

Fix Palworld Server Asking for New Character

# Technical Cause: GVAS Class Header Truncation

In containerized environments (Docker, Kubernetes, Pterodactyl) or servers with automated nightly restart scripts, process management utilities dispatch a standard SIGTERM signal. By default, container supervisors wait only 10 to 15 seconds before issuing a fatal SIGKILL.

Because Palworld dedicated servers manage multi-gigabyte memory pools, flushing dirty memory pages to disk takes substantial time. When a server process is terminated mid-write:

The Header Truncation Mechanics:

The file Players/<GUID>.sav is written to disk, but the GVAS binary header property save_game_class_name is cut off.
Instead of containing the valid class reflection path:
```
/Script/Pal.PalWorldPlayerSaveGame
```
It gets written as:
```
None.PalWorldPlayerSaveGame  (or  None)
```
Upon restart, Unreal Engine's class loader rejects the non-conforming header, treats the player as a first-time connection, and routes them to character generation.

01

Step 1: Immediately Stop the Server

Do not let players complete character creation! If a player creates a new character with the same Steam ID, the server will overwrite their corrupted <GUID>.sav file with a clean Level 1 file, making recovery more complex.

docker stop palworld-server
# or: sudo systemctl stop palworld-server

02

Step 2: Inspect Player Save Parity with CheckMySave

Download the server save directory from Pal/Saved/SaveGames/0/<WorldGUID>/.
Drag and drop the folder into CheckMySave.
CheckMySave inspects each file inside Players/ and correlates them against Level.sav records.
If any player has missing world records or corrupted headers, CheckMySave flags the exact player GUIDs.

03

Step 3: Restore Player File from Rolling Backups

Palworld's internal backup mechanism keeps rolling copies of player profiles:

Navigate to SaveGames/0/<WorldGUID>/backup/local/.
Locate the latest timestamp folder created prior to the server restart.
Copy the affected player's <GUID>.sav file from the backup folder.
Paste and overwrite the file into the active Players/ directory.

04

Step 4: Configure Safe Server Shutdown Timeouts

To prevent future mid-write corruption, adjust your server supervisor configuration:

docker-compose.yml Docker

services:
  palworld:
    image: thdev98/palworld-server-docker
    stop_grace_period: 60s    # Give server 60 seconds to flush dirty pages

systemd service Linux

[Service]
TimeoutStopSec=60

Before triggering automated backups or reboots via cron, always send an RCON command: save, sleep for 20 seconds, and then gracefully issue shutdown 30.