ich777

I hope that answers the question, but I see no reason to enable that by default:

Please see this post: or: or: and many other posts on the last few pages. Please also make sure that you enable write-back not write-through

I would recommend that you fully uninstall the plugin once, reboot your server and after that install the plugin again from the CA App, I have maybe found another bug which should be fixed with that.

Thank you, I will look into that and report back. That's maybe caused because you are on the private test branch. Please update the plugin to version 2024.04.29 and see if it is now working for you.

On what Unraid version are you?

Through a notification in the top right corner correct? Are you sure that you don't have a "Plugins Error" tab in the Plugins section from Unraid? If everything is working then leave it as it is, if you got issues then I would recommend installing this plugin again.

It is safe to uninstall it or don't install it anymore if you got no issues.

Can be a bit more specific? What did auto uninstall the driver? Are you sure that you don't have a new tab in the Plugins tab that is named "Plugins Error"? Did you wait until your server sent you a notification that it is safe to reboot when doing the upgrade? If you don't have any issues with the built in driver then the answer is: no.

Dann bitte im offiziellen Support Thread nachfragen, sieht so aus als wärst du nicht der einzige mit dem Problem.

Ich hab den Thread mal von Anleitung in den Allgemeinen support verschoben. Es wäre mal gut zu wissen welchen Container, sprich Repository bzw. von wem du verwendest? Hast du denn schon mal versucht 'maintenance' auf false zu setzen?

Please always stop the container, then edit the files and after that start the container. On what hardware do you run the container?

A bit more information would be nice please. Did you map the LUN properly to the Initiator name? It seems that Unraid is not able to connect to your Target, are you sure that your Target is running on port 3260? Can you ping your Target from Unraid? The plugin first tries to discover the Target with the specified IP and port, if that fails you see this message. You can also try this by issuing (from a Unraid Terminal) : iscsiadm -m discovery -t sendtargets -p 192.168.1.2:3260

Definitiv nicht, deaktiviert by default, auch nicht auf meinem test server den ich vor ein paar Wochen mal neu gemacht hab: Ein Scrub muss normalerweise immer manuell angestoßen werden und ist auch eigentlich nicht nötig da ZFS ein Journaling filesystem ist. Aber mal anders gefragt, warum ZFS im Array oder bist du einfach auf den ZFS Hypetrain aufgesprungen... Im Array ist jede Platte ein eigener Pool und macht nicht viel sinn, da ist das standard XFS auch ausreichend. Ich für meinen Teil gehe wieder auf BTRFS zurück in meinem Cache pool weil ich einen komischen Bug habe und den nicht wirklich (zuverlässig) reproduzieren kann, war sowieso mehr ein Test auf meinem Produktivsystem.

Was it running before or does it this since the first start? Can you share a screenshot from the Docker template please? To what path is the gamefiles set in the template? If you are using /mnt/cache/... make sure that the files are actually stay on the Cache and are not being moved to another Pool/Array. This usually indicates a network error of some sort but this error is pretty random.

I would really much report that to the Mega support. Not for now. Thanks for the link, I know of their repositories (I don't know why they upload them to their GitHub in the first place because that would much simplify the process. I would really see the issue solved in the first place and why this is happening. Maybe the support can provide you with the requested version for Debian 11 or 12 (preferably Debian 12), it's a bit unfortunate that they only keep the latest version in their download repository.

I'm also not sure if I can do anything about that since this sounds also like a game issue...

Glad to hear.... Sure, I already have a container for V-Rising (search for "v rising" <- with a space) :

I think you have only a few ports available in the free tier from Cloudflare even if you have more than one, if you want to use it with Cloudflare it would work but you have to switch over to the paid tier but to be honest I never looked into that but in general it should work.

Usually such containers are safe to expose to the Internet and forward the ports directly and as said above, there is not much benefit to route it through a reverse proxy (which is in general possible) since you are overcomplicating and maybe also introducing other weird behaviour or other issues.

Correct, that was what I was understanding from your previous post. These are usually ports which are used when a client is connected and is usually outbound, is the port 64319 outbound? <- It can also be the case that this is the master server which is pulling information from your server (Name, Players,...) Again, this is not like http/https traffic. I meant that this traffic is not http/https traffic, this is it's own traffic with it's own encryption, so to speak such sites that check for open ports can't detect that the port is open because they are only checking if the ports are answering a http/https request and game servers simply won't answer and therefore the port checking site will display the port as closed. May I ask if there are already other game servers running on your machine and if they are working?

Please update your container, already updated it.

They just released a new version... I already updated the container. (Maybe the found an issue which is with the new version fixed) I assume that's when you mount a share to the container where the share is meant to not stay on the cache drive or is this the case for all shares on the cache (which would not make much sense).

The main question is why? You usually create to a TS3 server via your hostname and port like host.com PORT You have to forward all ports since one is the query port, then there is one for the voice channel and one for data transfer. As said above you have to forward all ports because this is not a web server that proxies http/https traffic... Sure you could use streaming ports but the benefit from this is non existent and you are overcomplicating your setup. It is fine to forward the ports in your Firewall like it is for a game server (game servers are also not using http/https). You can read a bit more here where I write and rant about it a bit more (it's another application but it applies here too) :

No, this is just a display thing and because I don't expose any ports in the Dockerfile but that won't prevent the container from working. You will get the same on other container too where they don't expose ports, I'm also not a huge fan of exposing ports because it will always show a wrong port if you change the port in the game config and use eth0 or br0. Yes, because this is a game server and this is nothing like Plex (this was already discussed multiple times in this thread). Reason behind this is that such port check sites will only check for http/https and can't check if a port for a game server is open because game servers use their own proprietary protocol <- not http/https and game servers won't answer to such sites. Please forget about that, that doesn't matter at all, the container is running and is exposing the ports just fine. Are you sure that your NAT Reflection is working properly? Have you yet tried to connect from outside your LAN, I had many users where NAT Reflection was not working properly and they simply couldn't see their server from their own network.

How do you try to connect, which port have you set? This is a really game specific question and I think you have to look that up or at least ask on the SvenCoop Forums over here or here. This should not be related to the container itself.