ich777

Exactly, uinput is integrated a long time now into Unraid itself, so to speak, no need for a install anymore.

No, this is not possible. If you remove them from the Docker template the default values from the Dockerfile are read. May I ask with what values do you have an issue, the container exists a very long time now and nobody until yet reported an issue. Is it that bad when you have to use the Docker template for these few values instead the server.cfg?

I'm not 100% sure how you did that but nouveau is enabled. 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GB206 [GeForce RTX 5060 Ti] [10de:2d04] (rev a1) Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:5351] Kernel driver in use: nvidia Kernel modules: nouveau, nvidia_drm, nvidia 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22eb] (rev a1) Subsystem: NVIDIA Corporation Device [10de:0000] And your GPU fell from the BUS: Aug 15 09:24:51 nas kernel: NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus. You also have a lot of entries in your syslog from Nvidia, was the card working before or did you just put it in your system. When the card falls from the bus this can have multiple reasons, please don't use a PCIe riser if you have one installed, try another slot, try to lower the PCIe Gen to 4 or even down to 3 speed, make sure your BIOS is up to date.

Post your Diagnostics, as pointed out in the first post since they are required to troubleshoot hardware issues

Usually not, Fix Common Problems won‘t change permissions on files/folders, correct @Squid Sorry for that but usually it should just work if you don‘t change permissions. I really can‘t tell what happened there, sorry.

Nope, that doesn‘t mean that the permissions are correct. I assume something changed the permissions in the folder or even something got deleted somehow and that‘s why the container is not working anymore. LXC works a bit different than Docker for example, each container has it’s own rootfs and when you change permission the containers won‘t start anymore meaning that they are bricked. There should be a big red warning on the settings page to never run the Unraid function „Fix Permission“ on the LXC share sonce this basically would break all containers.

Is this the full output from lxc-start -F <CONTAINERNAME> (please don't forget to include the -F) Did you by any chance change your docker network from macvlan to ipvlan or did you change any bridge network on Unraid itself to use eth0 instead of br0? The above is also not default. Did you possible issue new permissions on the LXC container directory? Usually the containers will still work but the error message that you've posted is not much.

Sorry, you have a lot custom things in your AMP configuration file, remove all of that and see if it then works. May I ask why are you passing through the Nvidia driver through to the container, also your method seems rather complicated and I assume this is the issue why it's not working, your installed Nvidia driver version: 570.86.16 you pass through files from driver: 565.77 You always can check from the command line what went wrong with: lxc-start -F CONTAINERNAME

GVT-g is only supported up to Intel 10th gen CPUs but you question has nothing to do with GVT-g. It would be also be better to ask that in the appropriate support thread from @binhex since this seems like it's related to Emby and not GVT-g. This also doesn't require a dedicated plugin, you just need to pass through the device /dev/dri but that is something you should ask in the support thread (you can get there by clicking the container icon on the Docker page within Unraid and click Support).

Only Intel Core Series and Xeon Series CPUs are supported for GVT-g, Pentium and Atom Series CPUs are not supported (like mentioned in the first post).

I would recommend that you upgrade to 7.1.4 to begin with, never mind I just read that you are already on 7.1.4. I think that won't change much but it shouldn't hurt to enable GuC and HuC Since we are dealing with Docker that won't do much I think since these are primarily for VMs. This is not a troubleshooting step since you give the container full access to the host and this is basically bad, Privileged should not be turned on whatsoever except you want to make everything insecure. :) If your've already have a Device mapping in the template that won't do much, which I assume you had because otherwise that wouldn't work, what basically means this is redundant and not necessary. I'm not too familiar with Firgate but you shouldn't have to do that and I'm also not sure if Firgate mounts anything in /dev/shm. Can't say anything to that because I'm not running Frigate. I don't think so because OpenVINO should work no matter what, except if you completely overload it or we are dealing with a hardware failure, or it could even be the case that the your iGPU doesn't fully support the OpenVINO implementation from Frigate <- but I don't think that's the issue. However it always depends on the implementation from Frigate how OpenVINO is used and you might need to pass through /dev/usb to your container, so to speaking a Device with the mapping: /dev/bus/usb:/dev/bus/usb

Yes.

I assume you've set the docker container up using the command line with docker run, that's why you are seeing 3rd part.

Please update the container itself, the issue with BepInEx is now fixed, if you did any workarounds delete the version file for BepInEx which is located in the main directory from the container (usually named BepInEx-<VERSION>) in the first place and then update the container.

Are you talking about ValheimPlus or BepInEx? I try to look into this but I'm nut sure when I have time for a fix.

Yes: https://github.com/ich777/docker-minecraft-basic-server/blob/master/scripts/start-server.sh#L86 https://github.com/ich777/docker-minecraft-basic-server/blob/master/scripts/start-server.sh#L73 https://github.com/ich777/docker-minecraft-basic-server/blob/master/scripts/start-server.sh#L60 https://github.com/ich777/docker-minecraft-basic-server/blob/master/scripts/start-server.sh#L47 https://github.com/ich777/docker-minecraft-basic-server/blob/master/scripts/start-server.sh#L34 https://github.com/ich777/docker-minecraft-basic-server/blob/master/scripts/start-server.sh#L25

Okay wegn that all also doesn‘t work then something else is wrong. Are you sure that the container has access to GitHub and you are not blocking any traffic? Male sure to disable all AdBlockers if you have any on your network. Do you also have Unifi gear on your network? Sometimes IDS/IPS is a bit to strict on those devices and restrict access for containers to some sites.

Please try to remove the runtime folder from your minecraft directory alongside with any jar zip/tar file in the main directory from minecraft. Of course stop the container before doing any of that and then start the container.

Sure, just set RUNTIME_NAME to jre21 which you can find in Show more ... in the template.

I don‘t understand what you mean with that? The open source driver is compiled once when a new Unraid version is released. Again, this is most of the times a hardware incompatibility issue. Did you yet try to upgrade to Unraid 7.2.0 beta siereis and look if the open source driver is working there?

If your hardware ID is listed here then yes: GitHubGitHub - NVIDIA/open-gpu-kernel-modules: NVIDIA Linux ope...NVIDIA Linux open GPU kernel module source. Contribute to NVIDIA/open-gpu-kernel-modules development by creating an account on GitHub.

No. The closed source driver branch will not work with 50 series cards, if you are using a 50series card then you have to use the open source branch. Your 1660Ti won‘t work with the open source branch, only the proprietary driver will work with the 1660Ti since it’s Pascal based.

On the open source version for Unraid 7.1.4 there are of course fewer downloads but there are about combined 1.5k downloads: name: 6.12.24-Unraid, name: nvidia-565.77-6.12.24-Unraid-1.txz, download_count: 645, name: nvidia-570.144-6.12.24-Unraid-1.txz, download_count: 1657, name: nvidia-570.153.02-6.12.24-Unraid-1.txz, download_count: 2176, name: nvidia-570.169-6.12.24-Unraid-1.txz, download_count: 2199, name: nvidia-570.172.08-6.12.24-Unraid-1.txz, download_count: 1933, name: nvidia-570.181-6.12.24-Unraid-1.txz, download_count: 1044, name: nvidia-575.51.02-6.12.24-Unraid-1.txz, download_count: 14675, name: nvidia-575.57.08-6.12.24-Unraid-1.txz, download_count: 10183, name: nvidia-575.64-6.12.24-Unraid-1.txz, download_count: 8852, name: nvidia-575.64.03-6.12.24-Unraid-1.txz, download_count: 10937, name: nvidia-575.64.05-6.12.24-Unraid-1.txz, download_count: 8365, name: nvidia-580.65.06-6.12.24-Unraid-1.txz, download_count: 4722, name: nvos-570.144-6.12.24-Unraid-1.txz, download_count: 684, name: nvos-575.57.08-6.12.24-Unraid-1.txz, download_count: 828, (the last two who are starting with the name "nvos-") I assume you are not on Unraid 7.2 beta series correct?

I don‘t think so because otherwise more users would report that issue. About 10 users reported issues from about 8k downloads so I assume this is a hardware incompatibility or another hardware related issue for these users.

Please update your BIOS, you are running a beta BIOS and there is already a newer BIOS version available, after that make sure to enable Above 4G Decoding and Resizable BAR Support.