Repository navigation
Docs gap: Kubernetes device-plugin GPU passthrough breaks OpenCL (tone-mapping) while VAAPI works, due to /dev/dri/by-path/* ownership #336
Description
Is there an existing issue for this?
- I have searched the existing issues
Description
Running this image under Kubernetes with a device plugin (e.g. Intel's intel-device-plugins-for-kubernetes), instead of a plain Docker --device /dev/dri bind mount, breaks OpenCL while VAAPI/QSV keep working.
Cause:
- The device plugin exposes
/dev/dri/renderD128and/dev/dri/card0, chownedroot:root. /dev/dri/by-path/pci-<addr>-renderand-cardare also present (same major:minor), but the device plugin doesn't manage them — they keep the host's own group (render/video, arbitrary GID).- Intel's OpenCL/NEO runtime opens the
by-pathrender node, notrenderD128. VAAPI/QSV work; OpenCL (Dolby Vision tone-mapping) fails, ffmpeg exit 237 (AVERROR(ENODEV)).
Fix: ATTACHED_DEVICES_PERMS=/dev/dri — same mechanism as #284 / #305. find /dev/dri -print recurses into by-path/ and covers the mismatched GID.
Evidence
Device ownership mismatch inside the container:
$ ls -la /dev/dri/ /dev/dri/by-path/
crw-rw---- 1 root root 226, 0 card0
crw-rw---- 1 root root 226, 128 renderD128
crw-rw---- 1 root video 226, 0 by-path/pci-0000:00:02.0-card
crw-rw---- 1 root 992 226, 128 by-path/pci-0000:00:02.0-render
strace on clinfo as the non-root PUID user, filtered to the relevant call:
openat(AT_FDCWD, "/dev/dri/by-path/pci-0000:00:02.0-render", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)
Resulting ffmpeg failure:
[AVHWDeviceContext] Failed to get number of OpenCL platforms: -1001.
Device creation failed: -19.
Failed to set value 'opencl=ocl@va' for option 'init_hw_device': No such device
ATTACHED_DEVICES_PERMS=/dev/dri picking it up correctly on container start:
**** permissions for /dev/dri/renderD128 are good ****
**** permissions for /dev/dri/card0 are good ****
**** creating group groupXXXX with id 992 ****
**** adding /dev/dri/by-path/pci-0000:00:02.0-render to group groupXXXX with id 992 ****
**** adding /dev/dri/by-path/pci-0000:00:02.0-card to group video with id 44 ****
Suggestion
Add a line to the hardware-acceleration docs: under Kubernetes/device-plugin setups, if VAAPI/QSV work but OpenCL-dependent features fail with ffmpeg exit 237, check /dev/dri/by-path/* group ownership. ATTACHED_DEVICES_PERMS=/dev/dri covers it.
Activity
github-actions commentedon Aug 30, 2026
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
venturemavenwill commentedon Sep 22, 2026
Related documentation suggestion: distinguish overriding the device search
paths from disabling automatic permission handling.
In the Ubuntu base image, an explicitly empty
ATTACHED_DEVICES_PERMSskipsinit-device-permsentirely. This also skips automatic supplementary-groupsetup, not just
chmod, so users choosing this opt-out must arrange appropriatedevice access themselves.
For customized deployments where host device modes must remain unchanged, a
root-owned startup hook can add only the necessary nonroot device groups
instead. That approach worked in a local downstream Jetson setup across
container recreation, without changing the image's permission defaults.
This is an optional documentation point, not a proposed fix for the Kubernetes
case above, a recommendation to disable the default behavior generally, or a
request to add official Jetson support. Would documenting the empty-value
behavior and its group-access trade-off alongside this variable be useful?
Sources:
This comment was prepared with AI assistance. No patch, runtime, driver,
media, private configuration or log attachments are proposed.