+1 for game loads for ages then just disconnects without any server logs

I cannot say, maybe read back some of the pages, people had the problem and many different thing were done by different user. The container itself does work, there's some networking or configuration issue somewhere.

Figured it out, the port mapping instructions are wrong but I had to actually think about it. Leave the "game parameter" and config file at 7777 and only change the port values in the screenshot. Query port doesn't matter.

8 minutes ago, zee said:

Figured it out, the port mapping instructions are wrong but I had to actually think about it. Leave the "game parameter" and config file at 7777 and only change the port values in the screenshot. Query port doesn't matter.

No it's your firewall that is not configured properly. What you are doing here is this.

The docker container run on port 7777, but you expose those port for outside connection as port 7779. That mean now to connect to the server, you specify port 7779 instead of 7777. Your screenshot clearly show container port 7777. The server still listen on port 7777. So if it doesn't work when you change the exposed port to 7777, it means it's a you problem, something is in conflict on your unraid server or network.

Instruction clearly state to use the exact same port mapping as the game parameters you use. Yes, you can "cheat" and only change the exposed port and then firewall outside connection to that expose port, I've done it many time which is a very lazy way of doing things and could lead to problem (like game showing in the server list with the wrong port, unless you also forward port 7777 externally to 7779 internally). Also you must change the port in the conf if you change it.

In the end, if it's working now, it means your other thing you put on port 7777 that you talked earlier is causing problem. You might have firewall rules in place or other configuration that are making conflict.

It's not a container nor a template issue, nor even bad information. 7777 is the official port you can found on the steam page and official game FAQ. The dev are having a hard time updating everything, they themselves said only Udp at first but people found out TCP was needed also.

Edited April 27Apr 27 by Nodiaque

No it's your firewall that is not configured properly.

No firewall. You can't connect to a server listening on 7779 if docker is set to "-p 7779:7777".

If you change the port the gameserver is listening on you have to remove the port settings in the template and create them yourself.

Edited April 27Apr 27 by zee

8 minutes ago, zee said:

No firewall. You can't connect to a server listening on 7779 if docker is set to "-p 7779:7777".

If you change the port the gameserver is listening on you have to remove the port settings in the template and create them yourself.

Why is your server listening on port 7779? The game is listening on port 7777. The game parameters shows it, the game config file shows it, even your own config shows it!

Paste a screenshot of the docker advance view of your windrose container. It should show both the lan and container port. You can blur out your ip.

edit: Also, I would like to point out that you are the only one with this docker that have the port problem. All other person are running the server as port 7777 no problem.

edit 2: What I'm talking about docker advance view is this

edit 3: Just saw your edit. What you are saying about removing the port is actually in the FAQ of the docker and also in the instruction

It's also not totally true. If you click Edit on the port, you can change the exposed and internal port.

The problem is in past version of unraid (and sometime), while it's changing in the template, it's not changing in the docker compose. Not always but it happen. So a good way to remove those possibilities is to instruct users to remove and recreate the binding.

But you don't seems to understand that what you did is forward the external port 7779 to internal 7777, which mean it's still listening on port 7777. You changed only the exposed port.

edit (last?): Please refer to this documentation, which some are listed in the FAQ on page 2, showing which port and how to configure properly the game to listen to a different port.

Dedicated Server Guide – Windrose

Steam Community :: Guide :: Windrose | Dedicated Server

Once you provide screenshot, we'll be able to show you what you did and explain what's going on.

Edited April 27Apr 27 by Nodiaque

Why is your server listening on port 7779? The game is listening on port 7777. The game parameters shows it, the game config file shows it, even your own config shows it!

It's not when you change "game parameters" and the ServerDescription.json

44 minutes ago, zee said:

It's not when you change "game parameters" and the ServerDescription.json

You seems to not want to provide the requested information to help you. You don't seems to understand what you did and don't read properly what I'm saying. You take just a part and say "I'm not talking about that" while not taking the information in the whole section. I didn't blindly talked about game parameters and serverdescription, I explain what those settings do.

I mean no disrespect by the question I'm about to ask, are you not English native? I'm asking because language barrier are sometime a wall and if French is better, I can help in French in PM. Unfortunately, if it's neither of those, I can't help in another language.

Do you know what happened when you changed the value here?

Click on edit, it will be like that

Notice only 1 value changed, HOST PORT? This is also called exposed port. Notice Container Port is still 7777? This mean, in the container, it will receive whatever data is sent at port 7779 from the host and he will receive it at that port.

So to be even more clear, let's break in image how docker networking work. It's like a small router (well in fact, it is). So container port is like your lan port and host port your wan port. Whatever you put in WAN port (Host) has nothing to do with where the server is listening. You could put port 65023 here and it will work if you say, when connecting to your server, use port 65023. Does it mean the server is listening to that port? Not at all. It's port forwarding. The server is still listening on port 7777. In fact, the server and container has no idea about that, it don't care at all about all of that. You could delete the entire config and it will still run and listen on port 7777. Just like if you start a web server on your pc and don't forward incoming stream from port 80 to that server, the server will still listen to port 80 but nothing will work. You could use port 8080 on your router (which is what most people did in the past since 80 was blocked) and forward it to port 80 inside. You server doesn't listen to port 8080, it's still listening to port 80. That's what you did.

I'm trying to help you here understand how things work, specially to prevent other people on taking your information as fact when they are wrong. Provide requested information and we'll be able to make everything clear for you.

Edited April 27Apr 27 by Nodiaque

On 4/23/2026 at 12:36 AM, suchamoneypit said:

I cant seem to get my server to boot up; it hangs at the same spot every time in the docker logs:

R5LogPreloader: Display: [000064] UR5Preloader::Load Start preloading GenlandiaMulty [D:\Source\Build\work\gameRepoCheckoutDir\Source\R5Preloader\Private\R5Preloader.cpp:39]

I've deleted everything and retried a few times. Tried host and bridge. It doesnt seem to be a networking thing, it just never gets past this preloading. If i try to connect via direct IP or share code, it just loads for a bit and then dumps me to the main menu with no message.

I had someone say that its normal for the server to sit there until someone connects; its not. I setup a windows server 2025 VM to run this server instead after all the troubleshooting I've been doing and there is pretty clear additional logs that output after that line. There is both additional logs once this succeeds and a ton of logs that show up on connections from other players.

For some reason I could never get the server to get past that point in the logs, it always hangs right there. This I believe is preventing the server from starting up whatsoever, so nothing networking wise was working.

I also was never able to get the server working with DirectConnect on docker or in windows server. On windows server, I left DirectConnect off, and in my OPNsense router I added the UPnP plugin, enabled it, and setup a default-deny all with rules just for this specific server and it started working flawlessly using the share code. After doing that, I tried the same UPnP setup with this docker container and it still failed because the server still just sat indefinitely at:

 5LogPreloader: Display: [000064] UR5Preloader::Load Start preloading GenlandiaMulty [D:\Source\Build\work\gameRepoCheckoutDir\Source\R5Preloader\Private\R5Preloader.cpp:39]

So in summary after trying like everything I can think of including all mentions in this thread:

On docker:

DirectConnect and P2P/UPnP don't work, server just hangs during preload. No successful launches.

WindowsServer2025:

DirectConnect not working, UPnP is. Regardless, server never has any trouble starting up the server itself successfully

And like I mentioned before, this is running on my "GamerServer" unraid machine which host other servers, internal and external just fine. LAN and WAN players. Including an AbioticFactor Server that can use port 7777. So I don't understand why this specific docker container would be plagued with networking issues when others are not, which is what people seem to think is going on. I'm still pretty confident in my initial assessment that the server should not be hanging during that preload like it is regardless and I'm not even getting to any networking because the server isn't properly starting.

Anyways, Im running it and have a bunch of players using the Windows Server virtual machine now, so Im happy with my setup, but I wanted to share my results because I spent hours on this trying to get it to work. I am certainly no expert but I have 4 unraid servers and an array of services/servers so Idk why this single container would be having networking problems. I did consider weird permissions issues but I did run the Docker Safe New Perms tool early in troubleshooting.

Edited April 27Apr 27 by suchamoneypit

7 hours ago, suchamoneypit said:

I had someone say that its normal for the server to sit there until someone connects; its not. I setup a windows server 2025 VM to run this server instead after all the troubleshooting I've been doing and there is pretty clear additional logs that output after that line. There is both additional logs once this succeeds and a ton of logs that show up on connections from other players.

For some reason I could never get the server to get past that point in the logs, it always hangs right there. This I believe is preventing the server from starting up whatsoever, so nothing networking wise was working.

I also was never able to get the server working with DirectConnect on docker or in windows server. On windows server, I left DirectConnect off, and in my OPNsense router I added the UPnP plugin, enabled it, and setup a default-deny all with rules just for this specific server and it started working flawlessly using the share code. After doing that, I tried the same UPnP setup with this docker container and it still failed because the server still just sat indefinitely at:

 5LogPreloader: Display: [000064] UR5Preloader::Load Start preloading GenlandiaMulty [D:\Source\Build\work\gameRepoCheckoutDir\Source\R5Preloader\Private\R5Preloader.cpp:39]

So in summary after trying like everything I can think of including all mentions in this thread:

On docker:

DirectConnect and P2P/UPnP don't work, server just hangs during preload. No successful launches.

WindowsServer2025:

DirectConnect not working, UPnP is. Regardless, server never has any trouble starting up the server itself successfully

And like I mentioned before, this is running on my "GamerServer" unraid machine which host other servers, internal and external just fine. LAN and WAN players. Including an AbioticFactor Server that can use port 7777. So I don't understand why this specific docker container would be plagued with networking issues when others are not, which is what people seem to think is going on. I'm still pretty confident in my initial assessment that the server should not be hanging during that preload like it is regardless and I'm not even getting to any networking because the server isn't properly starting.

Anyways, Im running it and have a bunch of players using the Windows Server virtual machine now, so Im happy with my setup, but I wanted to share my results because I spent hours on this trying to get it to work. I am certainly no expert but I have 4 unraid servers and an array of services/servers so Idk why this single container would be having networking problems. I did consider weird permissions issues but I did run the Docker Safe New Perms tool early in troubleshooting.

i can say safely that the game right now have a lot of problem. Don't forget it's not linux native. Looking at the Windrose Steam forum, issue running in docker is common. Did you try putting the docker into host mode instead of bridge or other network? This is one of the many fix people are using, specially with p2p. I do not own the game, so I cannot test anything. I'm relying on people here that asked for it and they said it was normal, that it started logging more stuff once someone logged in. I myself had a friend playing on my server and it was hanging there before he connected. So I cannot say.

Another thing is the lack of clear instruction from the dev. The direct connection method isn't properly documented and it's through user trial that it was documented on the forum.

edit: Just saw you did say you tried host. I don't know what to tell you :(

Edited April 27Apr 27 by Nodiaque

I've pushed a new docker nodiaque/steamcmd:windrose-beta. The main difference here is wine 11.0 vs wine 10.0. It was suggested to update wine to latest version to fix some problem. If someone want to test, simply change the repository and run. I strongly suggest doing a backup of the appdata before just in case.

ok so I'm not too sure what's going on

I've touched nothing and done nothing and had a successful server running for about a week now, now I'm getting this error and it refuses to start.

from what I can tell, its stuck in a boot loop due to Wine?

is that on windrose or windrose-xvfb, or windrose-beta?

I do see a wine error like if it doesn't have permission to access file. Can you chmod and chown your appdata to be sure it's properly set?

Edited April 28Apr 28 by Nodiaque

2 minutes ago, Nodiaque said:

is that on windrose or windrose-xvfb, or windrose-beta?

I saw the apply update function in unraid so I updated that, but it was happening before I did that as well. Seem to have started happening randomly around early hours of the morning my time for no apparent reason.

hmmmm the docker itself was updated only 3 days ago. Can you check under repository what you have?

9 hours ago, Nodiaque said:

hmmmm the docker itself was updated only 3 days ago. Can you check under repository what you have?

i think windrose-beta, its worked fine for many days so far so i'm a bit confused why its not working now

Edited April 28Apr 28 by iLordShade

windrose-beta is brand new from today, using a different wine. You have to manually input this in the repository to use it. You can revert to windrose or windrose-xvfb if that's the case. Although I didn't had your issue with windrose-beta

ok so a complete reboot of the array actually fixed it. not sure how but my server is working again.

That sometime happen. I had some trouble like that in the past with my dockers (and other things in unraid) where full reboot fixed it. Never had anyone actually find out why.

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.exe

Do 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.

2 hours ago, Drider said:

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.exe

Do 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.

You can try to force the update using the tip in post #2. Maybe it will clear it. I just tried installing the docker and it worked no problem.

There's also a new docker using wine 11 instead of wine 10, tag windrose-beta instead of windrose. Might help with performance

I updated the docker port settings as per post #2, and forwarded the ports on my router. I am able to direct connect and play the game, but joining via invite code no longer works. Is that expected or is there some problem with the Query port that I need to troubleshoot?

27 minutes ago, BennyJ said:

I updated the docker port settings as per post #2, and forwarded the ports on my router. I am able to direct connect and play the game, but joining via invite code no longer works. Is that expected or is there some problem with the Query port that I need to troubleshoot?

As documented on the docker itself and in the windrose page, it's one or the other

I have an odd situation. I've done all the port forwarding correctly, as direct connection works just fine. But I would prefer to use the invite code.

I've followed the documentation, disabled direct connection, and removed the assigned ports, and ensured UPnP is enabled on the router. But every time I attempt to connect I receive the following error:

I've tried rebooting server, rebooting array, changing the container from all the different branches, it just doesn't connect.

Not the end of the world, as direct connection still works. But the invite code enables you to rejoin servers using the recently connected servers list. If you have direct connection enabled then the recent servers list doesn't work.

EDIT: Also, I've tried the new "Force Relay" option to see if that would work. That still doesn't resolve the issue either.

Edited April 30Apr 30 by GenericUnraidUser

5 hours ago, Nodiaque said:

You can try to force the update using the tip in post #2. Maybe it will clear it. I just tried installing the docker and it worked no problem.

There's also a new docker using wine 11 instead of wine 10, tag windrose-beta instead of windrose. Might help with performance

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.