Manual_config doesn't seems to work, and reset the configFile about palworld-server

[Fox8ter]

I'm on linux

[Fox8ter]

Here log for a startup

2024-01-31 09:41:01,711 INFO waiting for crond to stop
2024-01-31 09:41:01,711 INFO waiting for palworld-server to stop
2024-01-31 09:41:01,711 INFO stopped: crond (terminated by SIGTERM)
2024-01-31 09:41:01,711 INFO stopped: palworld-server (exit status 143)
2024-01-31 09:41:02,826 INFO spawned: 'palworld-backup' with pid 1239
2024-01-31 09:41:02,826 INFO success: palworld-backup entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2024-01-31 09:41:03,117 INFO exited: palworld-backup (exit status 0; expected)
2024-01-31 09:41:09,259 WARN For [program:crond], AUTO logging used for stderr_logfile without rollover, set maxbytes > 0 to avoid filling up filesystem unintentionally
2024-01-31 09:41:09,259 WARN For [program:palworld-bootstrap], AUTO logging used for stderr_logfile without rollover, set maxbytes > 0 to avoid filling up filesystem unintentionally
2024-01-31 09:41:09,259 WARN For [program:palworld-updater], AUTO logging used for stderr_logfile without rollover, set maxbytes > 0 to avoid filling up filesystem unintentionally
2024-01-31 09:41:09,259 WARN For [program:palworld-server], AUTO logging used for stderr_logfile without rollover, set maxbytes > 0 to avoid filling up filesystem unintentionally
2024-01-31 09:41:09,259 WARN For [program:palworld-backup], AUTO logging used for stderr_logfile without rollover, set maxbytes > 0 to avoid filling up filesystem unintentionally
2024-01-31 09:41:09,259 WARN For [program:palworld-backup-and-restart], AUTO logging used for stderr_logfile without rollover, set maxbytes > 0 to avoid filling up filesystem unintentionally
2024-01-31 09:41:09,259 WARN For [program:palworld-backup-and-update], AUTO logging used for stderr_logfile without rollover, set maxbytes > 0 to avoid filling up filesystem unintentionally
2024-01-31 09:41:09,259 INFO Set uid to user 0 succeeded
2024-01-31 09:41:09,563 INFO RPC interface 'supervisor' initialized
2024-01-31 09:41:09,563 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2024-01-31 09:41:09,563 INFO supervisord started with pid 13
2024-01-31 09:41:10,567 INFO spawned: 'crond' with pid 14
2024-01-31 09:41:10,569 INFO spawned: 'palworld-bootstrap' with pid 15
2024-01-31 09:41:10,571 INFO success: palworld-bootstrap entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2024-01-31 09:41:10,702 INFO spawned: 'palworld-updater' with pid 21
2024-01-31 09:41:10,702 INFO success: palworld-updater entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2024-01-31 09:41:10,715 INFO exited: palworld-bootstrap (exit status 0; expected)
2024-01-31 09:41:11,676 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-01-31 09:41:29,679 INFO spawned: 'palworld-server' with pid 95
2024-01-31 09:42:15,046 INFO success: palworld-server entered RUNNING state, process has stayed up for > than 45 seconds (startsecs)
2024-01-31 09:42:15,062 INFO exited: palworld-updater (exit status 0; expected)

[Fox8ter]

can this extra volume attachement be a problem (and generate a conflict?)?
-v $HOME/palworld/saved:/palworld/server/Pal/Saved

Because when i browse it from my machine, it seems to be empty..

But when i go to my extra volume it's ok

[Johnny-Knighten]

Hey, sorry that you had a problem!

For starters, that fourth volume mount does look suspect (-v $HOME/palworld/saved:/palworld/server/Pal/Saved). Nested volume mounts are not supported by Docker; however, it will be a feature soon, but there is no timeline when it will be available. See here and here for more details.

Regardless I decided to run your exact command on my system to see what happens. I'm testing on Windows using WSL2 (Ubuntu) atm since it was the quickest platform for me to test on.

Test 1 - Recreate Your Issue

So this is the first run of the command, with non of the volume mounts existing.

 docker run -d \
  --name palworld-server \
  -p 8211:8211/udp \
  -p 25575:25575/tcp \
  -p 27015:27015/udp \
  -e MANUAL_CONFIG=True \
  -v $HOME/palworld/server:/palworld/server \
  -v $HOME/palworld/logs:/palworld/logs \
  -v $HOME/palworld/backups:/palworld/backups \
  -v $HOME/palworld/saved:/palworld/server/Pal/Saved \
  johnnyknighten/palworld-server:latest

So this seemed to match what you are seeing, with $HOME/palworld/server/Pal/saved being empty and $HOME/palworld/saved actually containing files. Here is the relevant output of $ tree ~/palworld:

/home/johnny/palworld
├── backups
├── logs
│   └── supervisord.log
├── saved
│   ├── Config
│   │   ├── CrashReportClient
│   │   │   └── UECC-Linux-9979125F19474183B52F08EE987A51CD
│   │   │       └── CrashReportClient.ini
│   │   └── LinuxServer
...
│   │       ├── PalWorldSettings.ini
...
│   ├── ImGui
│   └── SaveGames
│       └── 0
│           └── DE19246CC8AD43C69F66B8E0E6ED801B
│               ├── Level.sav
│               └── LevelMeta.sav
└── server
    ├── DefaultPalWorldSettings.ini
    ├── Pal
    │   └── Saved (this is empty)
    ├── PalServer.sh
...

I also went inside the container to make sure the volumes were mapped correctly and it looked good to go:

root@c010b2071e9a:/palworld/server/Pal/Saved/Config/LinuxServer# ls
ApexDestruction.ini        Composure.ini         DeviceProfiles.ini            FullBodyIK.ini        GameplayTags.ini  LiveLink.ini          Niagara.ini           Scalability.ini
CameraCalibrationCore.ini  ConcertSyncCore.ini   EditorScriptingUtilities.ini  GLTFExporter.ini      Hardware.ini      LiveLinkCamera.ini    PalWorldSettings.ini  Synthesis.ini
CommonUI.ini               ControlRig.ini        Engine.ini                    Game.ini              ImGui.ini         MediaIOFramework.ini  Paper2D.ini           VariantManagerContent.ini
Compat.ini                 DatasmithContent.ini  EnhancedInput.ini             GameUserSettings.ini  Input.ini         Metasound.ini         RuntimeOptions.ini    Wwise.ini

So next I went and modified PalWorldSettings.ini inside the container using nano.

More specifically i adjusted ServerName from Containerized Palworld Server to Test.

[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Test,...

I quickly did a sanity test and checked the file from inside the container to make sure the changes persisted.

root@c010b2071e9a:/palworld/server# cat Pal/Saved/Config/LinuxServer/PalWorldSettings.ini 
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Test,...

Then checked from WSL side and it also had the changes.

johnny@Johnny-Desktop ~/palworld $ cat saved/Config/LinuxServer/PalWorldSettings.ini
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Test,...

I then stopped the container(docker container stop palworld-server) and started (docker container start palworld-server) it again to see if the changes persisted.

From inside the container I checked the file again and it reverted back to Containerized Palworld Server.

root@c010b2071e9a:/palworld/server# cat Pal/Saved/Config/LinuxServer/PalWorldSettings.ini 
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Containerized Palworld Server,...

I also checked from WSL side and it also had reverted back to Containerized Palworld Server.

johnny@Johnny-Desktop ~/palworld $ cat saved/Config/LinuxServer/PalWorldSettings.ini
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Containerized Palworld Server,...

I then checked the logs and the auto config generation is not running which is expected:

2024-01-31 13:56:17 Palworld Server Bootstrap - Skipping PalWorldSettings.ini Generation MANAUL_CONFIG is True

So I can 100% recreate your issue.

Test 2 - Drop The Extra Volume Mount

I still suspect that the fourth volume mount is the issue. It was a long time ago, but I remember at one point using a nested volume mount and it caused me a lot of issues, specifically with files being overwritten.

I wiped all my data from ~/palworld for a clean start. I just dropped the nested volume mount and ran the command again.

 docker run -d \
  --name palworld-server \
  -p 8211:8211/udp \
  -p 25575:25575/tcp \
  -p 27015:27015/udp \
  -e MANUAL_CONFIG=True \
  -v $HOME/palworld/server:/palworld/server \
  -v $HOME/palworld/logs:/palworld/logs \
  -v $HOME/palworld/backups:/palworld/backups \
  johnnyknighten/palworld-server:latest

Here is the tree output this time:

├── backups
├── logs
│   └── supervisord.log
└── server
...
    ├── Pal
    │   └── Saved
  ...
    │       ├── Config
...
    │       │   └── LinuxServer
...
    │       │       ├── PalWorldSettings.ini
...
    │       └── ImGui

Next I went and modified PalWorldSettings.ini inside the container using nano.

[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Test,...

Verified the change inside the container:

root@fd7e92a055e6:/palworld/server# cat Pal/Saved/Config/LinuxServer/PalWorldSettings.ini 
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Test,RCONEnabled=True,AdminPassword=adminpassword,PublicIP=,ServerDescription=A Containerized Palworld Server)

Verified the change from WSL side:

johnny@Johnny-Desktop ~/palworld $ cat ./server/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Test,RCONEnabled=True,AdminPassword=adminpassword,PublicIP=,ServerDescription=A Containerized Palworld Server)

I then stopped the container(docker container stop palworld-server) and started (docker container start palworld-server) it again to see if the changes persisted.

From inside the container I checked the file again and the changes persisted this time, the server name was still Test.

root@fd7e92a055e6:/palworld/server# cat ./Pal/Saved/Config/LinuxServer/PalWorldSettings.ini 
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Test,RCONEnabled=True,AdminPassword=adminpassword,PublicIP=,ServerDescription=A Containerized Palworld Server)

I also checked from WSL side and it also had the changes persisted, the server name was still Test.

johnny@Johnny-Desktop ~/palworld $ cat ./server/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini
[/Script/Pal.PalGameWorldSettings]
OptionSettings=(ServerPlayerMaxNum=32,ServerPassword=,RCONPort=25575,PublicPort=8211,ServerName=Test,RCONEnabled=True,AdminPassword=adminpassword,PublicIP=,ServerDescription=A Containerized Palworld Server)

Conclusion

I think the issue you are having is 100% related to that nested bind mount. I can't 100% speak to what is happening at the technical level, but I can speculate a little.

This is just conjecture, but I think the additional volume mount is causing two versions of /palworld/server/Pal/Saved to exist. One is tied to the $HOME/palworld/server mount and the other to the $HOME/palworld/saved mount. I am assuming there is some type of ordering in terms of which mount is created first and read from first. I'm thinking the $HOME/palworld/server mount is created first and then the $HOME/palworld/saved mount is created. The $HOME/palworld/saved mount is just copying the data from the $HOME/palworld/server mount since data already exists in the location it is being mounted to. Essentially I think $HOME/palworld/server is being shadowed by $HOME/palworld/saved. When we modify data in /palworld/server/Pal/Saved, changes are being made in the $HOME/palworld/saved mount, but not the $HOME/palworld/server mount. When we restart the container, the $HOME/palworld/server mount is loaded first which contains the original unmodified data. Then the $HOME/palworld/saved mount is loaded, but again because data already exists where its being mounted to, it is just copying the data from the $HOME/palworld/server. Thus we end up in a cycle of never seeing your changes being persisted.

Again conjecture but I think it does a good job of explaining what may be happening.

Let me know if dropping the extra volume mount works for you!

[Fox8ter]

Omg, thx for all that investigations.

Is there a y risk that changing config reset thé actual serveur instance ? And all thé progress ?

Regards

[Johnny-Knighten]

It isn't so much changing the config will cause an issue, it goes back to the one mount shadowing the other will cause an issue. The $HOME/palworld/saved/SaveGames/... directory contains the server saves, so they are at risk of being over written just like your config file. So I would expect restarting the server would wipe your progression.

Here is what I would recommend to prevent data loss.

1. Start a bash shell inside the container and execute supervisorctl stop palworld-server
   • This will stop the server itself and not stop the whole container
   • We are doing this first to prevent any more server data being written before we make a backup
   • You can do this in a single like this: docker exec -it palworld-server supervisorctl stop palworld-server
     • You should see palworld-server: stopped if it stopped successfully
2. Now with the server stopped, make a copy of your $HOME/palworld/saved directory
3. Now stop your container completely with docker container stop palworld-server
4. Inside your $HOME/palworld/server directory create $HOME/palworld/server/Pal/Saved then copy the backup you made in step 2 inside that directory.
5. Finally restart the container but first remove -v $HOME/palworld/saved:/palworld/server/Pal/Saved from your docker run command

Note - I have seen some people say you need to run the world save command in game to make an official backup. In all my experience with my own private server I have not needed to do so. But if you want to be extra safe do these steps before doing the ones above:

1. Log into your server
2. Open the chat window and enter `/AdminPassword
3. In the chat window execute /Save
4. Then perform the steps above

[Fox8ter]

I follow everything, and it work like a charm ^^
Really thanks...

[Johnny-Knighten]

No worries!

I am going to go ahead and close this issue. If anything else pops up feel free to reopen this one if its related or open and new one.

Glad I could help!