1 hour ago, GenericUnraidUser said:

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.

Try switching to host network. People have many problem using the invite code way.

11 minutes ago, Drider said:

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.

Nice catch, I'll fix the typo

7 hours ago, Nodiaque said:

Try switching to host network. People have many problem using the invite code way.

Nice catch, I'll fix the typo

Thanks for the advice, I've swapped to host network but it still isn't working unfortunately.

I'll try nuking the container and resetting it.

For the windrose docker, is there a way to not auto update on reboot? Finally got online working and friend can connect externally. Want to lock everything down so it only upgrades when I want it to so i can make sure we all update at the same time and have no issues like i have in past.

Keep up the great work!

Just now, FunkeyMonkey said:

For the windrose docker, is there a way to not auto update on reboot? Finally got online working and friend can connect externally. Want to lock everything down so it only upgrades when I want it to so i can make sure we all update at the same time and have no issues like i have in past.

Keep up the great work!

The server will not work if the client is updated, which steam does itself on all you friends. Thus locking it down won't make it work forever.

The steamcmd is responsible for everything related to update. You might be lucky and have steamcmd not detect there's an update and continue (happen way too often to be honest). But like I said, your friend won't be able to connect.

A game update shouldn't make your server not working anymore. But that's the dev job.

Just started the container after a few weeks because I'm about to travel for work and wanted to test it out. However, it's now in some sort of loop. Spits out these error messages and then re-starts... spits out the same error messages, re-starts... etc..

I've nuked the /appdata/Windrose folder. Pulled down the windrose folder again fresh. Starts fine. The error occurs when I copy over my world folder now from my localPC to the /appdata/Windrose folder and try to start the container.

Maybe some permission error or something?

LogOutputDevice: Error: === Crash Stack Trace: ===
LogOutputDevice: Error: 
LogOutputDevice: Error: [Callstack] 0x0000000141475686 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x000000014413ba9d WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00000001414024b3 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000141370d0a WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000149139e6f WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00000001490ff629 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x000000014451e1d9 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000144500f21 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000144500903 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x000000014c01d8e9 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00006ffff91f1074 VCRUNTIME140_1.dll!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00006ffff91f239c VCRUNTIME140_1.dll!call_catch_block4() [Z:\usr\src\packages\BUILD\dlls\msvcrt\handler4.c:440]
LogOutputDevice: Error: [Callstack] 0x00006fffffc3f869 ntdll.dll!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000144ee2abe WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000146b76117 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000146adbd13 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000146b51a9e WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000141427842 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000146a6a404 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000146a72458 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x000000014141ec48 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x000000014128a9d1 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000141284e7f WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00000001416e7ec5 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00000001416ee665 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00000001416e971e WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00000001416c088f WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00000001438550d0 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000144101b61 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x000000014410512c WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00000001441051aa WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x0000000144105c1d WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x000000014410b094 WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x000000014bf6aace WindroseServer-Win64-Shipping.exe!UnknownFunction []
LogOutputDevice: Error: [Callstack] 0x00006fffffa64819 kernel32.dll!BaseThreadInitThunk() [Z:\usr\src\packages\BUILD\dlls\kernel32\thread.c:61]
LogOutputDevice: Error: [Callstack] 0x00006fffffc3fa1b ntdll.dll!UnknownFunction []

Edited May 3May 3 by CoZ

I've read from someone in the thread that had same problem when copying over. There's a procedure on the official website on how more the world.

12 minutes ago, Nodiaque said:

I've read from someone in the thread that had same problem when copying over. There's a procedure on the official website on how more the world.

Yes. It's the same procedure I've used in the past to move over the world.

I cannot say, I don't run the game or the server but that is more of a question for the dev VS the container itself. This container follow the guide written on the dev site. Maybe try chmod 777 everything and see

While I haven't had any issues with running the server, and playing myself and with friends, I am running into challenges with getting mods to be utilized.

With the mod files (.pak, .ucas, .utoc) located in ...R5/Content/Paks/~mods it doesn't appear that they are being picked up and mounted when the server is starting.

All clients share the same mod files, and they work when playing single player. But when playing on the server, they are not active. Am I missing something?

It should be the same as when on windows. Verify the permission on the file, maybe the container can't access them

There was a patch this morning for windrose and when i restart my server to update I get this error. Now when trying to connect to the server it shows a version mismatch.

23 hours ago, Nodiaque said:

I cannot say, I don't run the game or the server but that is more of a question for the dev VS the container itself. This container follow the guide written on the dev site. Maybe try chmod 777 everything and see

I sent in a bug report with what I posted earlier, the errors.

I have been tinkering in the meantime. It seems that the P2pProxyAddress entry in the server.json MUST match the IP Unraid assigns it.

For example, I earlier had that P2pProxyAddress set to my tower's IP address of 192.168.X.XXX and it was working fine before the updates were pushed out. I've changed it to the internal IP set by the container (172.17.0.28) and I am no longer getting the crash/restart cycle.

2 minutes ago, sledgemaster said:

There was a patch this morning for windrose and when i restart my server to update I get this error. Now when trying to connect to the server it shows a version mismatch.

Got to post #2. You need to delete a file to "kick start" the update. It's been mentioned in this thread 30+ times now.

54 minutes ago, CoZ said:

I sent in a bug report with what I posted earlier, the errors.

I have been tinkering in the meantime. It seems that the P2pProxyAddress entry in the server.json MUST match the IP Unraid assigns it.

For example, I earlier had that P2pProxyAddress set to my tower's IP address of 192.168.X.XXX and it was working fine before the updates were pushed out. I've changed it to the internal IP set by the container (172.17.0.28) and I am no longer getting the crash/restart cycle.

My understanding of that is it for invite code mode, but I can be wrong. I'm saying that since the doc says

IP address used for listening sockets.

While there's 2 other config for direct connect but it says for futur usage.

14 minutes ago, Nodiaque said:

My understanding of that is it for invite code mode, but I can be wrong. I'm saying that since the doc says

IP address used for listening sockets.

While there's 2 other config for direct connect but it says for futur usage.

They aren't making it easy for us - they keep introducing breaking changes. Now for instance, since today's update, they've changed the location of the "world / save" folder.
I've fixed the crashing on the container start. I've figured out the new format for copying over a single player to the dedicated server with no crashes.
However, now I'm unable to connect anymore to the dedicated server as I could before with just the invite code. It's back to dropping me back into the main loading screen. Sigh. LoL

The worst is they don't update their doc. They have like 3 places for the doc and each says different thing.

9 hours ago, CoZ said:

Got to post #2. You need to delete a file to "kick start" the update. It's been mentioned in this thread 30+ times now.

So does anyone know if the update works at all on anyones? I'm having to delete this manifest for every update now. People claim this is a 'common' bug with steamCMD, but I run satisfactory via unraid and I don't have these same issues.

1 hour ago, dotikk said:

So does anyone know if the update works at all on anyones? I'm having to delete this manifest for every update now. People claim this is a 'common' bug with steamCMD, but I run satisfactory via unraid and I don't have these same issues.

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

3 hours ago, dotikk said:

So does anyone know if the update works at all on anyones? I'm having to delete this manifest for every update now. People claim this is a 'common' bug with steamCMD, but I run satisfactory via unraid and I don't have these same issues.

their own doc says to do that or validate. Having to run validate to update is bad and shouldn't be needed.

You can try with validate. Add a new env called VALIDATE and set it true in the unraid template. It will add the validate statement on the steamcmd.

Edited May 5May 5 by Nodiaque

On 5/4/2026 at 10:45 PM, Nodiaque said:

their own doc says to do that or validate. Having to run validate to update is bad and shouldn't be needed.

You can try with validate. Add a new env called VALIDATE and set it true in the unraid template. It will add the validate statement on the steamcmd.

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

Just create a new env variable from the unraid template ui, put VALIDATE as name and true as value

For anyone that is/was having issues copying the single player world over to the dedicated server, they've changed how it's done (again). The easiest way that I have found is to copy the entire \Username\appdata\local\R5\Saved\SaveProfiles\{Bunch of random numbers' folder\RocksDB and the RocksDB_V2 folders over to your \appdata\windrose saved world location.

Then go into your windrose directory on your server, delete everything out of RocksDB and RocksDB_V2 folders that IS NOT "worlds" subdirectoy.

There was an issue with the patch changing the RocksDB to RocksDB_V2 and the single player world not migrating correctly blah blah blah. I tried every which way to get it to "stick" otherwise it would just create a new world and overwrite any changes to the Serverdescription.json file that you put into it.

Edited May 6May 6 by CoZ

On 5/3/2026 at 4:59 PM, Nodiaque said:

It should be the same as when on windows. Verify the permission on the file, maybe the container can't access them

Permissions are fine. Folder shows up just fine, and no access restrictions

20 hours ago, pirosvx said:

Permissions are fine. Folder shows up just fine, and no access restrictions

Stuff have changed in a patch recently even for mods. Check the official game documentation.

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?