Drider

Ok, that all makes sense, and I appreciate your explanation in such detail. I may start diving in to this in the next few weeks, but I'm much farther behind in the learning process as I'd be starting from basics. If I can find anything relevant or helpful, I'll do what I can to offer it up here, in hope that it may also help you in the long run. Thanks again!

So,.. If I understand correctly, what you are trying to get working is the "update available" recognition of unRaid, and this to some degree does require automation, so that the GUI can recognize there is indeed an update available? Sorry I've I'm still misunderstanding, I read your reply like 5 times, trying to get what you're saying. Like I said, I've never built a container, but just installed via CA. Though I do feel like I'm getting to point I may invest to the time to learn how to do this stuff manually, as it might be a skill worth learning, for the future administration of my several servers.

you know,.. I was just thinking.. It doesn't' exactly have to be automated updates. Even just that it checks the image for updates, and reports back in the unRaid GUI there's an update available, and gives the user the option to apply update would be enough, (basically, the normal docker update behavior, see image). Of course automation of image update would be nice, as the host of the sever might not be checking daily, but I personally don't feel entirely necessary, as long as we can run the update process through he GUI, and not have to rebuild the container manually each update.

Yeah, I only linked it as I thought maybe it might give you an idea or two. Glad to hear it did, and look forward to seeing if you can find progress for automation. Good luck!

Maybe what he's done here can shed some light. Maybe you can build off his Image? pfeiffermax/windrose-dedicated-server - Docker Image The Nerdy Tech Blog I tried my damnest to get a docker working from his, but I've honestly never setup a docker outside of Community Apps, and I just didn't have the time to invest learning what the hell I'm doing. He's gotten it set up where his docker will update, as long as Kraken Express pushes updates to the Linux distro (Which it looks like they are maintaining). I'm confident they will eventually set a SteamCMD distro, its' just a question of when. I personally am interested in a Linux binary without the WINE on top purely because of server resources. Just as an example, Running a Palworld Docker, (which is very similar to WR), in pure Linux Binaries vs Wine is a night and day difference when it come to resources. I'm hoping to see a similar difference with Windrose.

No problem at all, thanks for the reply, and get well!

I was looking around for a Palworld Docker container and found this. I just wanted to add, we were having the same issues with SteamCMD not recognizing updates for a Windrose docker container, and having to also delete the Appmanifest_*.acf however after adding a Validate variable to the container, it forces a refresh check for updates each time the server is restarted . Not saying it will be the solution here, but it might, and won't hurt anything to add:

The new update was pushed, with the Linux based version for docker, any chance you might be pushing a new version?

I think the question is being asked because a new update is around the corner that is going to now support/Add Docker Images with Linux server support. Windrose - Patch Notes, version: 0.10.0.7 - Steam News Patch Notes, version: 0.10.0.7 Linux Dedicated Server Support + Small Improvements Hey, everyone! We are releasing another batch of small improvements and fixes for the current build. Please note that we'll also be performing some backend maintenance, which means the game will be temporarily unavailable. We apologize for the inconvenience and appreciate your patience. Patch notes, version: 0.10.0.7 Added Docker images with Linux server support. For setup instructions, see DedicatedServer.md in the dedicated server root directory. Added Traditional Chinese language support. Sails can once again be damaged by cannonball hits. P.S. Another development blog is coming soon. Stay tuned! So I guess the question should've been, Will you be updating/adding the docker for the full Linux version that may avoid the need for WINE, and possibly reduce overhead / increase server performance? I for one would prefer to use your container if so, as I've had near zero issues with your Dockers

You either miss-understood, miss-read, or didn't read the FAQ's from the second post I linked you in my fist reply. It's gives pretty clearly 3 options to solve the SteamCMD update error your are receiving, non of them telling you to delete your save data OR anything about editing the ServerDescritpion.json. I would suggest you read it again, there is really no other way to summarize the solutions.

Check the FAQ's in the second post. https://forums.unraid.net/topic/151809-support-nodiaque-gameserver-docker/#findComment-1358893 Clear the .json as described, set the +Validate Flag, and never worry about it again.

The errors are the product of the last patch Kraken Express put out last week. They are calls to the Development Libraries on the actual dev machines that we don't have as server hosts / players. It's widely known the verbosity of the logs and the amount of null reporting due to issue like this make reading the actual errors of the log files hard as hell. These errors should not be an issue, however, Kraken Express does need to address this, and soon, as the logfiles could get out of hand with the number of errors recorded per hour. I'd just keep an eye on the size of your log files if you have a few players and your server runs 24/7. It really should not be a problem you need to worry about. Regarding your saves/world: This is not an issue of the docker or the server, this is an issue of the Update Kraken Express put out back on May 5th If you join the discord server for Windrose, and look at this guide post I had pinned: https://discord.com/channels/1260209458924224542/1493764667074412797/1501115366062035065 You'll find solutions in the guide, links to discussions, and links to the FAQ's from Kraken Express with solutions to your World save issue. All have solved this for numerous users.

Couple quick questions regarding the Enshrouded containers: I'm currently running the Windrose docker, I assume if I install enshrouded it's going to reinstall SteamCMD over top my existing SteamCMD install, but that shouldn't effect anything? Or is there a way to skip the SteaMCMD installation since I've already installed from Windrose's docker? Which version is the better option Enshrouded or Enshrouded_Proton ? I'm looking for the least amount of overhead and stability, based on the little I read so far in this thread that would be the Proton version?

Would you mind posting a screen of what this would look like? I'd actually like to test this.

I've only had to delete it once, typically it updates just fine via SteamCMD.

Nuking the appmanifest_4129620.acf resolved the error and my server was indeed able to update, thanks for the pointer. Heads up tho: You refer to appminifest_*.json in the second post, it's actually appmanifest_*.acf you want to remove/rename if updates fail.

So there was a large optimization patch to Windrose this morning, and I tested on my Windows 8.1 Enterprise VM. The CPU usage, and high disk write have definitely been solved, and the game seems to run much better in that environment. With that, I was super hopeful to test the Docker version, however it seems like the server application is failing to update through SteamCMD in the docker: Secifically: Error! App '4129620' state is 0x6 after update job. ---Starting...--- ---Update SteamCMD--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' Logging directory: '/serverdata/Steam/logs' [ 0%] Checking for available updates... [----] Verifying installation... UpdateUI: skip show logo Steam Console Client (c) Valve Corporation - version 1777415795 -- type 'quit' to exit -- Loading Steam API...IPC function call IClientUtils::GetSteamRealm took too long: 48 msec OK Connecting anonymously to Steam Public...OK Waiting for client config...OK Waiting for user info...OK Unloading Steam API...OK ---Update Server--- Redirecting stderr to '/serverdata/Steam/logs/stderr.txt' Logging directory: '/serverdata/Steam/logs' [ 0%] Checking for available updates... [----] Verifying installation... UpdateUI: skip show logo Steam Console Client (c) Valve Corporation - version 1777415795 -- type 'quit' to exit -- Loading Steam API...IPC function call IClientUtils::GetSteamRealm took too long: 47 msec OK "@sSteamCmdForcePlatformType" = "windows" Connecting anonymously to Steam Public...OK Waiting for client config...OK Waiting for user info...OK Update state (0x0) unknown, progress: 0.00 (0 / 0) Error! App '4129620' state is 0x6 after update job. Unloading Steam API...OK ---Checking if WINE workdirectory is present--- ---WINE workdirectory found--- ---Checking if WINE is properly installed--- ---WINE properly set up--- ---Prepare Server--- ---Server ready--- ---Start Server--- Starting Windrose dedicated server Executable: /serverdata/serverfiles/R5/Binaries/Win64/WindroseServer-Win64-Shipping.exeDo I need to repull the docker image, or is there something else going on? I was under the impression the server will update every time we restart the docker.

Yes I miss-typed, I meant I set Network to Custom Br0, then assigned the IP

I only every ran the docker with network Type set to host. I then assigned an internal IP, open and available, outside my DHCP pool, managed by my Gateway. Local IP connection, and remote connection via testing VPS from New York, to my gateway's external IP both worked from the start after setting my ServerDescription.json , "similar" to how you've set yours. You're issue definitely sounds of networking configuration. Are you by chance running a vLAN on the same host as where your Docker resides with your Winrose server, and/or a vLAN within your gateway local network/internet traffic? Outside of networking within unRAID, specifically if you're indeed running a vLAN, I would start looking at network configurations outside your unRAID server

Just to make sure,.. You have Forwarded ports 7777 and 7778 UDP to your host IP for the server right? Also when running direct IP connection invite codes will no longer work.

So, I set up this container on my UnRAID server, (Was currently running Windrose server in a Windows 8.1 Enterprise VM on one of my unRAID servers. Had no real issues getting it up and running, as well as importing my saved world, and verifying everything loaded correctly. I didn't get to testing mods, but pretty sure most will work as they did normally on the Windows VM (at least the ones you place in <\content\pak\~mods> UE4SS mods seem to not be there yet, and crash/lag the servers I've tested pretty bad so far). The problem I had, and the reason I stopped testing, and went back to running on the Window 8.1 VM, the CPU usage is CRAZY in comparison, Honestly it makes Windows 8.1 look like the best OS ever made from Microsoft, (Which is all honesty watching the CPU Threads balance across 4 cores + 4Threads Pinned and dedicated, (Both were pinned and isolated for the Docker, and The VM) the win 8.1 is beautiful. Load balancing couldn't be split up better between all cores and threads, (even when no players are in the server, and CPU usage spikes, and I so hope the devs fix this soon) The problem with the docker container I found in my system, there simply is no load balance, from the start of the server, regardless if players are connected or not, 2 of the non threaded cores immediately spike to 100% usage, and never come down. other assigned cores/threads barely ever take any load. (This was testes using the same pinning and isolation for both the Win8.1 VM and the container one at a time.) I only bring this up because it's so surprising to me a docker would take so much more overhead over a VM, but I have to assume WINE is just not running as efficient, or it's multiplying the poor resource optimization of the Windrose Server. At least for now I'll be sticking with my Windows 8.1 Enterprise VM as the differences were extremely noticeable by users in game, but plan to check back when hopefully more optimization has been made. Thanks for your efforts with the docker.

Hmm.. I did recently relocate my servers from the racks in my office, back down to the racks in my basement,.. Perhaps one of the breakout cables wiggled around and is causing it? Maybe I'll go down and wiggle the wires a little and see if it goes away,..

I would've included the diag, just figured this has come up a few times, and was recognized, and there might be quick "pop it out, check it here", kinda answer. Diag attached -Thanks colossus-diagnostics-20240813-0432.zip

Greetings fellow unRaiders! Been a few years since I last posted, happened to go through my system logs today and found a couple errors, (2 servers, one on each), hoping just to get some quick feedback. Both servers running 6.12.11 First server: Servers been going strong for 6ys now no issues Error seems to stem from the SSD Cache pool, and started 05:00 yesterday morning with the TRIM scheduler task Aug 11 05:00:16 Colossus kernel: critical target error, dev sdg, sector 975284261 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 2 I confirmed again by manually running TRIM: Aug 12 18:58:40 Colossus kernel: critical target error, dev sdg, sector 975284261 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 2 Is the SSD Toast? Second server Running close to 10 yrs Been having Memory issues when I try to get the board back up to 128GB, still can't tell if it's a memory stick in one of my second sets, or one of the memory banks on the board itself (ASRock EP2C602-4L/D16) For the time being, I've just gone back to 64GB but the issue is every time I boot now, I get this in the log. I've read it's nothing to be concerned about a long as the server isn't throwing actual memory errors, (which it's not), just wanted to make sure that's the case. (I'll continue the hunt for the actual memory error in the system later if so) Aug 7 00:08:50 Juggernaut mcelog: Kernel in lockdown. Cannot enable DIMM error location reporting Thanks for the feedback, and your time!

I did try this, no fix. However interestingly enough, two reboots later, and it's back to what it was.