DockerBubba

Two things (first should be easy!) 1) I change the Container Variable SEED to some number, but upon restart, the server is using exactly the same (empty) seed! 2) Is there an easy way to change some of the default settings in the server.properties file (like: online-mode=true) that are not exposed to the Unraid container update page?

With respect to the /dontstarve/token directory, what is the default install structure? My friend's is completely different than mine with a separate uniquely-named folder and two(!) copies of the Cluster_1 directory and three instances of cluster.ini! BUT, it works on my server! My structure is: /dontstarve - /token -- /Cluster_1 --- /Caves --- /Master --- adminlist.txt --- cluster.ini --- cluster_token.txt Follow-up: My friend was just messing around with "backup" directories, but, regardless, when I copied his /dontstarve folder to my /appdata and changed the cluster.ini to my settings, it works perfectly, no duplication! Is there an easy way to force-install a completely clean /steamcmd directory? I guess you could shut-down your Steam-related apps, delete /steamcmd and then install something completely new and that should re-create it?

I just removed and re-installed the instance (making sure to completely delete the /dontstarve folder prior to re-install, again) This time, I'll add the token and make incredibly minor changes to the cluster.ini, like just the name and password, even though hardly anything else was changed in any case. Follow-up: Nope, same thing... Completely vanilla install, only changed the game name, password and type (game type made no difference in the past). There are really only two possibilities: - the /steamcmd directory holds something that is messing it up - the cluster token is somehow messing it up Hmmm... Follow-up #2: Tried a cluster token from a friends server, no difference, still two joinable games show-up (yes, he shut-down his instance! ) This time, I changed the game name and password ONLY!

The install is pure vanilla from the Docker repository, with only minor changes to the cluster.ini for name, game type, etc. Anyhoo, here are the two log files from a clean-start... masterLog.0 cavesLog.0

cluster_token.txt Are the logs stored somewhere in the /dontstarve folder? The unRAID log window always slows down Firefox and will sometime crash! Also, I found the the instructions vague and process to make, the cluster_token.txt file, incredibly convoluted. There wasn't any clear direction that it must come from the LOCAL (PC) client and that you also need to have a fully logged-in Klei account for it to generate. Seeing how I've already tried wiping and re-installing the entire unRAID /dontstarve directory, maybe it's a corrupt cluster_token.txt?

This is weird... I've asked on the Klei forums and got nowhere, but any ideas why my Don't Starve Together unRAID instance is creating TWO distinctly separate worlds to join? They share the same preferences as set in the cluster.ini (game type, name, password, etc.) In the attached images you'll see that one is on Day 33 and one Day 9; both completely playable!

Wooooo! That seemed to do the trick! The log is behaving normally and it looks like it's installing (7 Days to Die) So, YES, update to 6.9.2 ASAP! That said, the Community Applications "homescreen" seemed to die after an update, but you can still search and install.

This is EXACTLY what is happening to me... There has been some kind of recent change in either Unraid, docker or maybe the way the gameserver dockers work now. It had been working flawlessly for more than a year now and its all gone to crap!

OK, I have no idea why a 7DTD update would cause so much grief! Now it seems that the 7DTD process has filled-up the Docker image itself, which should be impossible, no? The Docker volume and log were at 100%, so I did a purge and rebooted, but now the very first line in the log is: "/tmp/dumps insufficient permissions - delete and recreate"

When you choose and run the 7DTD container from Community Applications (using defaults), it DOES manage to make three empty directories, where you would expect them to be, so I don't think it's any kind of disk access issue.

There's only one drive attached to the system! I'll fire-up the other steam-centric containers again and then delete /steamcmd and re-try 7DTD.

Yes, the first thing I did was delete the container, delete the /7dtd directory and it made no difference. By the sounds of it, it's a steamcmd problem, not necessarily related to your 7dtd container. With that in mind, if I shut-down the other Steam-centric containers, can I delete the steamcmd directories and try to re-install 7dtd from scratch? Will that effect the other game servers that use steamcmd? Waay at the bottom of this thread is where I found a reference to the exact issue: https://githubmate.com/repo/MitchTalmadge/AMP-dockerized/issues/94

Any more insight on this error issue with the 7 Days to Die container deployment: "src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize.src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize." It's obviously a rare issue, but a couple of people running Unraid have ran into it, more importantly, on Satisfactory, not 7DTD, so it might be some broader issue. A friend suggested it might have to do with the optional Steam login fields, but are those ever relevant?

No, it's a pretty vanilla Unraid setup, but this first part of the log (which acts very odd, overwriting itself and not clearing from previous attempts) and it has an error right away: "deadlock "?: --- ---Checking if UID: 99 matches user--- ---Checking if GID: 100 matches user--- ---Setting umask to 000--- ---Checking for optional scripts--- ---No optional script found, continuing--- ---Starting...--- ---Update SteamCMD--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize. [ 0%] Checking for available updates... Thread failed to initialize src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize. Thread failed to initialize ---Update Server--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' Looks like steam didn't shutdown cleanly, scheduling immediate update check src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize. Thread failed to initialize [ 0%] Checking for available updates... src/tier0/threadtools.cpp (4085) : Probably deadlock or failure waiting for thread to initialize. Thread failed to initialize ---

The default: 294420 In the past it's never been difficult. This time, I simply add the container and leave all the settings to the defaults for now (ports, etc.) and after "apply" is does some typical preparatory stuff then gets no further. The initial report (this seems fine...): --- Pulling image: ich777/steamcmd:7dtd IMAGE ID [7dtd]: Pulling from ich777/steamcmd. IMAGE ID [3ac06a45bc97]: Pulling fs layer. Downloading 100% of 30 MB. Verifying Checksum. Download complete. Extracting. Pull complete. IMAGE ID [5ecfdce331fd]: Pulling fs layer. Downloading 100% of 8 MB. Download complete. Extracting. Pull complete. IMAGE ID [397e02e644be]: Pulling fs layer. Downloading 100% of 10 MB. Verifying Checksum. Download complete. Extracting. Pull complete. IMAGE ID [bb5b24889a61]: Pulling fs layer. Downloading 100% of 2 KB. Verifying Checksum. Download complete. Extracting. Pull complete. IMAGE ID [e8e52096371b]: Pulling fs layer. Downloading 100% of 2 KB. Download complete. Extracting. Pull complete. IMAGE ID [7eff29bf6c41]: Pulling fs layer. Downloading 100% of 2 KB. Download complete. Extracting. Pull complete. Status: Downloaded newer image for ich777/steamcmd:7dtd TOTAL DATA PULLED: 48 MB Command:root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='7DaysToDie' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e 'GAME_ID'='294420' -e 'SERVERCONFIG'='serverconfig.xml' -e 'GAME_PARAMS'='-logfile 7DaysToDie_Data/output_log.txt $@' -e 'VALIDATE'='' -e 'ENABLE_BEPINEX'='false' -e 'USERNAME'='' -e 'PASSWRD'='' -e 'UID'='99' -e 'GID'='100' -p '26900:26900/tcp' -p '26900:26900/udp' -p '26901:26901/udp' -p '26902:26902/udp' -p '26903:26903/udp' -p '8080:8080/tcp' -p '8082:8082/tcp' -p '27015:27015/udp' -v '/mnt/user/appdata/steamcmd':'/serverdata/steamcmd':'rw' -v '/mnt/disk1/appdata/7dtd':'/serverdata/serverfiles':'rw' --restart=unless-stopped 'ich777/steamcmd:7dtd' 16c6a90f226c6c7707dafddc3a4c460243c8215b620c48b6c80942997749b6ef The command finished successfully! ---