Connecting throws load error for client_temp/server_save

@PeterA, @ScottHansen, @Jason, @Ipsquiggle - I'd appreciate any help on this! Please ping/contact/message me anytime if you need more information/logs etc. Thanks a lot for your input! Thanks for the great QOL update!

Is the error message suspicious because it mentions `client_temp`? Is this a server-side or a client-side problem?

The server log just prints this:

Quote

[00:06:00]: New incoming connection 192.168.0.1|51058 <...>
[00:06:00]: Client connected from [LAN] 192.168.0.1|51058 <...>
[00:06:00]: ValidateGameSessionToken ...
[00:06:01]: Client authenticated: (KU_...) thasmo
[00:06:01]: [Steam] Authenticated host '...'
[00:06:02]: There is no active event to validate against.
[00:06:06]: [Steam] SendUserDisconnect for '...'

 

Edited March 12, 2021 by thasmo

Hello,

Same problem on :

- dedicated  Don't Starve Together: 455519 LINUX ;

- ubuntu 20.04 64bits : Linux XXXX 5.8.0-41-generic #46~20.04.1-Ubuntu SMP Mon Jan 18 17:52:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Thank you for all your work !!

can you upload your server log of the server your joining?

@zarklord_klei, I've attached the server log to the bug report. Mind that the attached server and client logs are not from the same server/session/run.

Edited March 12, 2021 by thasmo

can you tell me what files are inside /opt/cluster\shard/save/server_temp folder?

@zarklord_klei i, ve attached all the cluster dir.

DST_455519_dedicated_ubuntu20.04.tgz

@zarklord_klei, inside /opt/storage/cluster/shard/save/server_temp/ there's a single file called server_save which seems to be some kind of binary/encoded file with a size of 348531 bytes. The files contents start with "KLEI     1DAQAAABAAAACyEBgA...".

Hmmm, that is weird, I think i have found the fix for this, but its hard to say for certain, please let me know if the next hotfix resolves this issue.

@zarklord_klei, is there an estimation when the next hotfix will be published? Before or after this weekend? Thanks!

Unless something crazy happens, sometime today.

@zarklord_klei, also, I noticed something different, probably not related, but after creating a `worldgenoverride.lua` file, somehow, when running `cat worldgenoverride.lua` it prints the contents with the string `KLEI 1` prepended to the file.

cat worldgenoverride.lua

KLEI     1 return {
        override_enabled = true,
        overrides = {
                extrastartingitems = "20",
                krampus = "often",
                regrowth = "veryfast",
                season_start = "summer",
                world_size = "huge",
        },
}

What is this behavior? Is this some left over debug code which accidently prepends this data to various files?

Edited March 12, 2021 by thasmo

in the new update, we added support for settings to get changed, because of this behavior, we must rewrite worldgenoverride.lua, if somebody ran a command that set wildfires to "often" it would just get wiped, so we instead update worldgenoverride.lua to include the current world settings, which will prevent that from happening.

@zarklord_klei, it seems the new patch/hotfix does not solve the issue. I'll attach a `zip` archive with the `cluster` directory so that you can have a look at it yourself.

I noticed that `client_temp/server_save` does not exist in the cluster directory, only `server_temp/server_save` exists.

Edited March 13, 2021 by thasmo

So, I just tested an older codebase and the problem doesn't occur there. I assume that the issue is not specific to DST alone, it seems that it's directly related to how we run the server. Could be some permission problem or something. Gonna have to look at it more closely.

I think I figured it out. It seems that directory and file permissions for some critical files/directories were somehow not set properly, although listing the files and directories, it looked okay. The issue seems to be related to how Docker (wrongly) applies file and directory permissions when building a Docker image.

If anyone is interested, this is how I applied permissions in the Dockerfile:

# Set permissions.
RUN set -ex \
	&& chown -R "$STEAM_USER":"$STEAM_USER" "$STEAM_HOME" \
	&& chmod -R +x "$STEAM_HOME/scripts/" \
	&& chmod +x /usr/local/bin/dontstarvetogether \
	&& chmod +x /entrypoint.sh

And this is what seems to have fixed it; note the last line:

# Set permissions.
RUN set -ex \
	&& chown -R "$STEAM_USER":"$STEAM_USER" "$STEAM_HOME" \
	&& chmod -R +x "$STEAM_HOME/scripts/" \
	&& chmod +x /usr/local/bin/dontstarvetogether \
	&& chmod +x /entrypoint.sh \
	&& sync

So, in the end, this probably was some permission problem due to how Docker sets those in the Docker image. If someone else has similar issues, be sure to check permissions for files and folders related to running the server and persisting the config files etc.

Edited March 13, 2021 by thasmo

PS: It's always permissions.

Removed the storage.zip, 'cause it contained some sensitive data (server token, KU_ ids etc.), I guess.

That was one of my guesses if the hotfix didn't fix it, glad you got it resolved.

Changed Status to Fixed