58 minutes ago, Acemodder said:

I know the 610 driver is locked to 5000 series

But that's what you say you have?

44 minutes ago, Kilrah said:

But that's what you say you have?

Sorry what do you mean? When I install the nvidia driver, it auto-installs the latest driver, but I swap it to download and update to 580 driver wihc should be correct for a blackwell card (5070ti). I have the drivers uninstalled currently, so my nvidia GPU isn't working properly (due to lack of drivers). But let me install it and show you some screenshots etc of the problems I'm getting.

So this is the process I did....

Installed the Nvidia driver package. It auto installs 610 driver.

I also disabled the docker as requested in the window.

I then downgraded/upgraded to driver version v595 which is the open source driver which is meant for Blackwell GPUs.

I rebooted my server to ensure the driver is loaded. As you can see it is, and the RTX5070ti is picked up by the O/S.

GPU stats plugin see's the GPU fine with no load.

At this point I enable Docker again in my unraid settings.

So I get after a short period of time, my WebUI dies, but docker containers still work in the background, plex/sabnzbd/sonarr/etc

But the only way to get my webUI back is to do a hard reset of the unraid PC. The GPU doesn't actually do anything in terms of processing, it's just showing no usage etc, it's like the OS refuses to the use the GPU.

Restting the WebUI services with this works via ssh command line, so the server is actually working, just the GPU crash locks the webui service.

/etc/rc.d/rc.php-fpm restart

/etc/rc.d/rc.nginx restart

Oh... I finally think I fixed it.

I changed my BIOS primary GPU to be ipgu and not the nvidia RTX5070ti, seems that has resolves it for now....

I will continue to monitor it though.

NVIDIA CDI/Legacy hooks fail with "cannot open /proc/self/fd/N" - Apears to be positional bug runc, not driver-specific.

Following up on my earlier posts in this thread (dual RTX 3060 setup) — I did a deep isolation test and found something that should help pinpoint the root cause.

Environment

• Unraid 7.2.5 (Docker 29.5.3, runc 1.3.5 — commit v1.3.5-0-g488fc13)

• Nvidia-Driver plugin, tested with three different driver versions: 610.57.04, then downgraded to 580.173.02 — same result on all

• 2x NVIDIA GeForce RTX 3060 (GA106), 01:00.0 and 03:00.0

• Host: nvidia-smi works perfectly, both GPUs detected and idle

Error:

Every method of GPU injection into a container fails with the exact same error:

docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running createContainer hook #3: exit status 2, stdout: , stderr: /bin/sh: 0: cannot open /proc/self/fd/12: No such file exit status 2

Tested and all failed identically:

• --gpus all

• --runtime=nvidia -e NVIDIA_VISIBLE_DEVICES=all -e NVIDIA_DRIVER_CAPABILITIES=all

• --device=nvidia.com/gpu=all (CDI)

• --device=nvidia.com/gpu=all --security-opt seccomp=unconfined

• no-pivot = true added under [nvidia-container-cli] in /etc/nvidia-container-runtime/config.toml

None of the above changed the outcome. Downgrading the driver three times did not help either.

Isolation test

I inspected the generated /etc/cdi/nvidia.yaml and counted the createContainer hooks in the order they're combined for the CDI device requested:

• --device=nvidia.com/gpu=all → hook #3 (0-indexed) lands on the big create-symlinks hook (the one linking ~30 .so files: libcuda.so, libnvidia-ml.so, etc.)

• --device=nvidia.com/gpu=0 (single GPU only, fewer total hooks) → hook #3 lands on a completely different hook: enable-cuda-compat

Both failed with the identical /proc/self/fd/12 error, at the same hook index, despite the hook content being different. it's runc failing deterministically once you reach the 4th createContainer hook execution in a sequence, regardless of content.

Workaround that worked

Manually edited /etc/cdi/nvidia.yaml to strip it down to just one hook (the essential create-symlinks for the core .so files), removing:

• per-device create-symlinks (/dev/dri/by-path links)

• the small gbm/glxserver symlink hook

• enable-cuda-compat

• update-ldcache

• disable-device-node-modification

With only 1 hook left, docker run --rm --device=nvidia.com/gpu=all ubuntu nvidia-smi succeeded, both GPUs showing correctly.

However, this breaks anything relying on ldconfig cache inside the container — confirmed when testing h264_nvenc via jrottenberg/ffmpeg:4.1-nvidia, which failed with Cannot load libcuda.so.1 (dynamic loader couldn't find the symlinked lib without an updated ldcache). Adding -e LD_LIBRARY_PATH=/usr/lib64 as a workaround for that specific case.

Given that Unraid 7.2.5 shipped a runc update specifically patching CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881 (procfs write-redirection / hook-related fixes), and the error signature (cannot open /proc/self/fd/N) matches exactly the kind of fd-handling path touched by that patch, I suspect there's a regression introduced by the runc hardening that breaks legitimate sequential OCI hook execution somewhere around the 4th hook.

Question:
Has anyone else hit this exact createContainer hook #N: /proc/self/fd error after updating to Unraid 7.2.5+ / runc 1.3.5?
Is there a known-good runc version pre-CVE-fix vs. post-fix that avoids this regression, or is this a brand new bug specific to runc 1.3.5?

has the nvidia driver broke... it was working last week.. yesterday my jellfin stopped working after a reboot found nvidia driver cant find my video card..

i tried to re download update.. it says its downloading but actually its not downloading anything... after a long time it says cant download... i uninstalled the plugin rebooted.. reinstalled the plugin i check my pfsense and the unraid server is not downloading the nvidia driver... is there something broken in the past week.

4 hours ago, comet424 said:

is there something broken in the past week.

by the mass using this i would rather say no ;) there woul dbe more posts about this.

most likely, dns (provider) issue for git access or broken USB devices, or not enough space (rather rare), and so on.

may test if your docker updates are still working, may try a VPN to bypass ...