ich777

Have you read my comment about passing through /mnt and not /, you should really consider doing it that way and that should work just fine. I also think there is some miss-understanding, luckyBackup can't deal with that. Please try to use /mnt

What path is set in your template for the game files? If you are using /mnt/cache/appdata/... you have to ensure that the files for the appdata share in this case stay on the Cache pool in this case and are not moved to the Array. You can however change the path to /mnt/user/appdata/... but some games have issues and wouldn't even start. The above described is most likely what happens to you because the mover is moving the data off of the Cache and to the Array and because you are using /mnt/cache/appdata/... it is not able to find the savegame/data anymore.

Because they are symlinks (hard links) to another directory, so to speak the real disk. No worries. I think you mean /mnt/user/(docker name) and /mnt/cache/appdata/(docker name) because the path /mnt/appdata/(docker name) doesn't exist usually. This is a think I can't answer, my container runs pure Debian with TurboVNC, noVNC and luckyBackup on top of it, nothing special. Do you run luckyBackup as root? However you should be able to do it like @Kilrah mentioned and map all folders individually but I would strongly recommend that you for mount the real disk which is used as exclusive share like /mnt/yourpoolname/ To take it a bit further you've said that if you mount it to /mnt/user it is not working, have you yet tried to mount /mnt instead of / to the container, this should also solve your issues... TBH I haven't looked that much into exclusive shares, from where are the hard links created and where they point to because I simply don't have any use case for them.

It's not a strict requirement. You have to download that to you mind. Usually if you've played The Forest you are good to go. In all seriousness, no, just download the container and start playing,... but please also stop playing the game if the fear that you are experiencing is too much for you.

I'm not too sure about this but have you yet tried R/W Slave in the Docker template? The main issue with symlinks is that they don't work correctly in Docker container most of the times if you pass them through from the host because Docker is isolated and usually don't follow symlinks on the host and since Exclusive shares are symlinks like @Kilrah already pointed out it doesn't work that well most of the times. Hope that makes some kind of sense to you.

Have you read the description from the container where it says you have to tick the box Console Mode for schedules?

Please disable Validation, that won't help, as said above this is only if you have issues that the container doesn't update the game properly. Is the container restarting or does it display Starting Server/the message that I've posted in my previous post? If the container is not restarting chances are high that it is running properly and some kind of network issue. Have you yet tried to do a direct connection simply by entering your specified IP for the container (in your case 192.168.1.169)? <- I would recommend that you leave it on the default bridge and not using br0 but that's of course up to you. Most of the times it's an issue with Hair Pin NAT that the server won't show up from your local network, have you yet tried to connect from outside your network or see if you can reach the server from outside your network with the ports forwarded in your router?

What path is set in terms of the Game Files? Do you use /mnt/cache/appdata/... or /mnt/user/appdata/...? If you have set the appdata share to be moved from the Cache to the Array by the Mover, that's the issue but I would strongly recommend that you leave your your appdata share always on the Cache and not move it to the Array, otherwise you have to set the path to /mnt/user/appdata/...

You simply can do that with a cron job via User Scripts. docker container restart CONTAINERNAME About the saves, the container usually should save the game when shutting down.

Geh doch einfach in die CA App (sprich der Apps Tab in Unraid) wie es auch in Fix Common Problems steht und such dort nach "r8168" dann findest du es. Dieser Link ist falsch und ich wüsste auch nicht warum du es so installieren willst, du brauchst immer den RAW link aber bitte, installer es über die CA App. Du siehst auch hier das du einen Error hast. BTW, wenn du das plugin installiert hast fordert es dich zum reboot auf nur falls du es überließt.

I can't confirm that, it is totally working in my case with the legacy parameters that are listed here. Anyways, I will look into it how it has to be modified to support the new settings.xml file. I've investigated a bit further and it seems to be recommended that you have indeed a settings.xml but that most commands are still passed over through the command line: Click

Without any further information hard to troubleshoot. Most likely it is a Docker container that is communicating with this URL.

That is maybe the best idea, I had to update the container since there was a slight change to the GitHub API where (which the container is utilizing) it wasn't able to grab the latest version number but that is now fixed. However I've tried to install it again and it is working fine, please keep in mind the first start might take a bit longer than usual since it installs dependencies:

Thanks for the report! I will look into that ASAP and will report back.

I've updated the container, please update the container itself and see if it fixes the issue (go to your Docker page in Unraid, enable Advanced View in the top right corner, click on "force update" at the container and wait for it to update, disable Advanced View).

Thanks for the report! I will look into that ASAP and report back. Sorry but I'm going to deprecate this container since it causes always trouble and I'm not exactly sure why. Anyways the main reason why it's not working is because the maintainer now switches to - instead of . at the releases for some reason and that change is not consistent on his download page/GitHub. GitHub lists the newest release as: 8193.36.9 His download server lists the release as: 8193.36-9 Sorry for not bringing better news but I think Beamdog now also has it's own Docker for NWN:EE see here.

Please stop the container, go to the directory for BeamNG-MP and delete the files: "BeamMP-Server" & "beamngmp_v...", start the container again. This should fix your issue. I've tried it on my server and it is pulling updates just fine:

The main issue is that I don't have such hardware on hand and it is really hard for me to support such specific plugins, I can of course create such a plugin but then I can give no support and have to maybe deprecate it for newer Kernels if it isn't working anymore. Anyways, I'll report back when I got a plugin package ready.

No, the node_exporter exports all metrics from your Unraid server as described in the description. What ports do you need to adjust? Do you have any port conflicts? Do you want to import the metrics on server A? Usually you just have to add the IP & Port from Server B Exporter plugins in Prometheus on Server A.

But that is not my container. I really can't help here since you have to ask in the support thread for the chormium container that you are using. Maybe you have to forward another port, I'm not that familiar with KasmVNC. As already said, nothing changed in the last two months for the OpenVPN container.

This needs to be a separate plugin and is nothing that I would like to implement in the existing IT87 plugin since these are basically two different things. Sure I can help with the driver package and compilation. Are you on Unraid 6.12.6? Give me a few days please. @Terebi, @somebody are you interested in maintaining the plugin (I can of course help with creating it), the compilation can be implemented in my toolchain so that it automatically get new packages every time a new Unraid version is released.

Nice, glad to hear that you've solved it. I would strongly recommend to not use /mnt/user/... instead use the real file path like /mnt/YOURDISK/... <- you can only do that if you set the Share settings for appdata to stay on the cache and is not moved over to the Array.

Did you restart the container a few times from what I can see in the log output correct? These lines indicates that the server was started correctly and is waiting for connections: [S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK. CAppInfoCacheReadFromDiskThread took 1 milliseconds to initialize Setting breakpad minidump AppID = 892970 SteamInternal_SetMinidumpSteamID: Caching Steam ID: 76561197960265728 [API loaded no] [S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded. (please also note that this message don't have to show up immediately and it can take some time to show up) Can you also share a bit more information since I really can't help with that little information. What are your settings in the template? Have you changed anything in the template? Do you use BepInEx or Valheim+? I assume you enable valdiation, please disable it <- this won't basically do nothing. If the container is not restarting it is usually started and waiting for connections.

Have you seen this button in the Settings: With that you can change the default permissions from: To: However this applies only to new files and that you upload to Mega with the client. The main problem is if you upload the files as root and have these permissions from above the client won't change them so you have to ensure that the permissions are correct when uploading.

Nothing changed in terms of OpenVPN, the last update that I pushed to it was about two months ago and if it was working in that timeframe then something else must have been changed. Are you sure that Chromium isn't the culprit? The log that you've attached it not from my container.