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?