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! ---

The 7 Days To Die container seems to be buggered since the recent (major) Alpha 20 update. Basically, with a vanilla set-up, it creates the root: \7dtd directory and two subdirectories: \Saves and \User, then it goes into an endless loop of failure message in the log: --- ---Prepare Server--- grep: /serverdata/serverfiles/serverconfig.xml: No such file or directory ---Creating SaveGameFolder config --- sed: can't read /serverdata/serverfiles/serverconfig.xml: No such file or directory ---Savegame location found--- grep: /serverdata/serverfiles/serverconfig.xml: No such file or directory ---Creating UserDataFolder config --- sed: can't read /serverdata/serverfiles/serverconfig.xml: No such file or directory ---UserDataFolder location found--- ---Server ready--- ---Start Server--- /opt/scripts/start-server.sh: line 169: /serverdata/serverfiles/7DaysToDieServer.x86_64: No such file or directory --- FYI, this is on UnRaid server and was working flawlessly, up until the A20 patch. Also, prior to re-trying it, I removed the container and completely deleted the original \7dtd directory. I didn't change the: \steamcmd directory since that is used by other containers, like Rust, Don't Starve and those are all working. Thoughts?

This is the part that's a bit strange to me... In your example, you set a container port to say 27016, but how does the game know to use that port unless it's specified somewhere? (I'm assuming the default is 27015) That's why I was asking about the "+1" idea with the serverconfig.xml; if you simply set the serverconfig to say 26905, does the game know to move-up the port numbering to find the rest of the ports used? Does the game "scan" though a range of ports? (seems unlikely...) In any case, when I duplicate (but shift +5 to 26905) my -working- OMV ports, the Unraid-hosted server can be seen by the in-game browser, but you get a timeout trying to connect. Something is missing, but I don't know what! FYI, switching to host mode works fine with the example attached (26905 and note the container ports shifted to match), but that's really not a "solution"! What makes it more complicated is that you really need to test connectivity though a VPN since servers on your LAN will appear to work fine, with settings that will fail for external clients.

Ah, OK... The only port I've ever seen in serverconfig.xml is a single instance of 26900. Are there other instances that need to be changed, or does it assume that's the base port and does +1, +2, etc. internally? Check on the "delete and replace", vs. simply trying to update the template. The last entry (UDP5) warns about that and if you change the serverconfig.xml, it follows... I'm just messing around with both platforms! OMV/Portainer works, but is a helluva lot more work to figure out and is sheer hell to try to get access to the /players directories! (Linux permissions are almost impassible and WinSCP is about the only option for file changes/additions) I just uploaded the Portainer image to show that a functioning server does not use 27015/16 in bridge mode. Thanks for the quick replies!

OK, to get the terminology straight, in your reply, the "config" you refer to is the list of port mappings under "Update Container"? (been there, done that...) Where would you see/edit the "template" in Unraid? Also, I don't follow what "redo it" refers to... (I had no overlaps since the mappings were all changed to 2790x, etc. and the other instance is running on a different box under OMV) Oh yeah, under OMV, I don't port-forward 27015/16 and it works fine! I suspect that 26900 TCP/UDP might actually be the only port needed! Sorry if the questions seem obvious, but it seems like it should be simple, but there's a core issue I'm not addressing!

Question: 7 Days to Die and multiple container instances and/or other existing servers and Bridge mode? More for curiosity and elegance, I'm trying to figure out how to make a 7DTD container that uses non-standard ports work in Bridge mode. I've got it to the point where an external user can connect via IP, bit the game is not advertised on the list. I can also get it to appear on the list, but it times-out trying to connect! There's (maybe) some magical combination of ports & forwarding that will make it work, but I haven't figured it out yet! (FYI, Host mode works, but that's cheezy and overkill and can cause other issues...) Also, I have a 7DTD server running on OMV/Portainer (didstopia/7dtd-server) with bridge mode and it works fine, albeit with the default ports.