ich777

bwrap needs '--cap-add=SYS_ADMIN' what I saw from my research, but keep in mind that I don't recommend running a container with privileged rights since this gives the container controll over the host, so to speak unRAID.

Sieh dir mal ZFS an, hab mittlerweile auf ZFS umgestellt und läuft super, brauchst nur ein paar Befehle eingeben im Terminal und fertig, läuft echt top mit dem Docker als pfad drauf, libvirt image usw...

I also can type whatever I want in there and even have set the libvirt.img to be on a ZFS Pool:

Try to run the container with privileged rights.

I've only ran lightweight games on it with Proton back in the days. Astroneer for example and it ran fine. Maybe a dependency is missing for it. Is WINE still needed for Proton, at least it was needed back in the early days from Proton by some games.

I would recommend that you open up a thread in the Bug Support sub forums with the Diagnostics attached from above so that the team can take a look at it.

In the past I have experienced this when I let a SSH session open and the shutdown also took forever. Try to close every SSH session to the server before shutting it down, i think the second parity check that you see in the screenshot was caused also by a SSH session that I've left running while rebooting or shutting down the server. But as you can see from the screenshots, no parity check was triggered in between the reboots. Sent from my C64

Tested it now and had no Parity Checks or whatsoever. Downgraded from 495.44 to 470.82.00: Then downgraded from 470.82.00 to 470.74: And lastly upgraded again from 470.74 to 495.44: Here is also the Parity History (please ignore the canceled ones that I did about half a month ago, I did that by accident... ) : Are you sure that you don't have a SSH session or something similar open? This also could lead to a unclean shutdown.

It also be possible that the developers have messed something up, this would not be the first time that this happened, maybe try to restart the container in the next few days 3 times a day or so and see if it actually pulls a update. It is possible but keep in mind that the container checks every time if you start/restart it if a new update from the game is available.

Have you restarted the container yet? The check for updates happens when the container is started/restarted. Maybe this also means that your game version that you run locally is outdated, try to validate the game files within Steam (you will find various tutorials if you search the web on how to do that).

Exactly, I really don't know the AMD hardware and how it works exactly with Virtualization, but I think it's worth a try to to test a VM from scratch without a BIOS file and the card not bound to VFIO and another one also without a BIOS file and bound to VFIO.

I will try to change the drivers on my main rig and will report back if have dirty shutdowns, please give me a few hours, I can't reboot it instantly...

Can you try to do a new VM "test" installation without a GPU BIOS file, I think @alturismo runs a system with two cards and also tested it without vfio and it just works fine.

I think so, this is pretty early alpha and as you can see a few above the developers broke the container because they added IPv6 but with a modification to the template everything is back to normal. My containers work as a dedicated server that is running on bare metal. The advantage from my containers is that the installation/update process from the game and the start from the dedicated server is automated.

If you are interested, crazycat69 posted this on the Github issue, maybe you can fix it yourself if you are interested:

And if you want to connect to targets from unRAID the initiator is here:

This is dependent on the graphics card and is maybe caused because the plugin utilizes nvidia-smi to get all the necessary information to display on the plugin page. Does the fan spin down again after that? I think you don't have persistneced mode on or am I wrong? This would be something for the support thread for the driver plugin.

From what I see in the log the Server is running. Have you installed Steam? Maybe try to add it in the Server Browser as a favorite. @Cyd do you have a guess what's wrong?

What do you mean with this? Does the server work, or what is the exact problem, do you have a log output? You can access it by entering the IP from your server or go to the Steam Server browser and add the IP:PORT as a favorite.

I've added this to the template so that on new installations it will work right OOB, will this be fixed from the developers? Thank you for the infromation.

I think the best bet would be DFP_NR since these are actually the output ports and this corresponds to the display output, if the container doesn't find the DFP_NR or better speaking the output port the X Server would also fail and complain about that display 0 is not available because well the output port is not found, very oversimplified and I also hope that makes a little sense to you... Sent from my C64

Naja aber diese SATA controller von Amazon sind doch auch ganz in Orndung und brauchen nicht sooo viel strom, hab sogar einen in einem mPCIe slot drin bei meinem Test Server. Muss aber auch noch dazu sagen ich bin nicht wirklich der Stromspar Meister was unRAID betrifft, das ding muss stabil laufen und Kompilieren und meine diversen Tests aushalten...

You have to reboot in between, since otherwise it won't work properly. Is this the only graphics card in your system? No, usually 0 is the default one and that should always work except if the container crashed or some other unusual thing happened. I think you also have tried different values at DFP_NR or am I wrong? As said above I would try to play around with the DFP_NR variable and reboot every time you change the value, I know this is a tedious process but I can't think of another way to do it. Maybe something about AMD is preventing this from working correctly, that's just a wild guess from me, but in terms of Virtualization they are a little behind Intel from what I read here on the forums, but that should have nothing to do with this container but maybe it affects it in some way.

@joroga22 I think the GT710 is not compatible, tried it now with my Nvidia T400 and it works just fine. Docker Log: ---Preparing Server--- ---Starting Server--- time="2021-11-03T22:09:11+01:00" level=info msg="Owncast v0.0.10-linux-64bit (737dbf9b1a444b0b7d415da819c16d74d3d7812e)" time="2021-11-03T22:09:11+01:00" level=info msg="Video transcoder started using x264 with 1 stream variants." time="2021-11-03T22:09:12+01:00" level=info msg="RTMP is accepting inbound streams on port 1935." time="2021-11-03T22:09:12+01:00" level=info msg="Web server is listening on IP 0.0.0.0 port 8080." time="2021-11-03T22:09:12+01:00" level=info msg="The web admin interface is available at /admin." time="2021-11-03T22:11:08+01:00" level=info msg="Inbound stream connected." time="2021-11-03T22:11:08+01:00" level=info msg="Video transcoder started using nvidia nvenc with 1 stream variants." time="2021-11-03T22:11:13+01:00" level=info msg="Inbound stream disconnected." time="2021-11-03T22:11:27+01:00" level=info msg="Inbound stream connected." time="2021-11-03T22:11:27+01:00" level=info msg="Video transcoder started using nvidia nvenc with 1 stream variants." time="2021-11-03T22:11:27+01:00" level=info msg="Inbound stream connected." time="2021-11-03T22:11:27+01:00" level=info msg="Video transcoder started using nvidia nvenc with 1 stream variants." Owncast Log: nvidia-smi output:

Jede angeschlossene Festplatte wird beim Start vom Array als Festplatte gezählt, egal ob im Cache, Array, Unassigned Devices oder nirgends eingebunden. Ja, aber USB im Array oder Cache bin ich kein Freund von, aber ja könnte man machen.