GPU Issue UGREEN
Posted by simplebenn
Issue: /dev/dri not passed into ANY container despite JELLYFINHWACCEL being set — hw overlay not merging Setup: UGREEN DXP4800 plus, SparkBox with tdarr and media modules enabled. Symptom: Tdarr QSV transcode fails with no output file produced / device creation error. Confirmed same failure pattern on Jellyfin hw transcoding. What I confirmed, in order: JELLYFINHWACCEL is set (not blank/none) in .env. Host-level check — /dev/dri is real and present on the DXP4800 host: crw-rw---- 1 root video 226, 0 Aug 3 16:47 card0 crw-rw---- 1 root render 226, 128 Aug 3 16:47 renderD128 (Regular shell user gets "Permission denied" on ls -l /dev/dri since it's not in video/render groups — but this doesn't matter for Docker, since dockerd runs as root and root can access these regardless.) Checked inside sb-tdarr: docker inspect -f '{{json .Mounts}}' sb-tdarr → no /dev/dri entry at all in the container's mounts. Restarted Tdarr (via dashboard restart action, twice) — container comes back healthy, 13+ min uptime, but /dev/dri still absent afterward. Cross-checked on a second container to rule out a Tdarr-specific bug: sudo docker exec sb-jellyfin-media ls -l /dev/dri → ls: cannot access '/dev/dri': No such file or directory Same failure on Jellyfin as Tdarr. Conclusion: This isn't a Tdarr-specific bug, a permissions issue, or something a restart fixes. Host has real DRI devices, JELLYFINHWACCEL is configured correctly, but the hw overlay (docker-compose.hw.yml) isn't being merged into any container on this box, even after force-recreate restarts. Looks like the overlay-merge logic itself isn't triggering here — needs a look from Tom's team rather than a client-side workaround.
5 replies
Chris wrote:
Great troubleshooting — you've actually pinned this down further than most reports we get. There's a known gap here: the GPU device only gets attached to a container when it's CREATED, so a container that was already running before the drive/hardware was ready (or before a restart) keeps whatever it was born with — a dashboard restart alone won't re-attach it. Run sudo sparkbox doctor first — it has a dedicated hardware-transcoding check and will tell you exactly which case you're in (missing overlay vs. a GID mismatch on the render group). Then force a recreate with sudo sparkbox up media and sudo sparkbox up tdarr — that rebuilds both containers with /dev/dri attached fresh. If doctor instead flags a GID mismatch, it'll print the exact set-env fix to pin it. Let us know what doctor reports if this doesn't clear it up!
simplebenn wrote:
After running those commands on my sparkbox I was able to see this output for my jellyfin server. sudo docker exec sb-jellyfin-media ls -l /dev/dri total 0 crw-rw---- 1 root video 226, 0 Aug 7 02:31 card0 crw-rw---- 1 root 105 226, 128 Aug 7 02:31 renderD128 doing this command for the tdarr one I do not get an output. sudo docker inspect -f '{{json .Mounts}}' sb-tdarr | grep dri
Chris wrote:
Nice, that confirms Jellyfin has its GPU device back after the recreate. Tdarr showing nothing from that grep means the device still isn't attached there, so this isn't fixed on our end yet, you didn't miss a step. Since you're already past what our built-in check would tell most people, can you run sudo sparkbox doctor anyway and paste just the hardware-transcoding part of its output? That'll show exactly what state it thinks Tdarr is in, which helps pin down why Tdarr's recreate isn't picking up the device the same way Jellyfin's did. I've sent this over to get looked into properly, thanks for the detailed logs, this is a big help.
simplebenn wrote:
[Hardware Transcoding] [OK] /dev/dri exists -- GPU devices detected total 0 drwxr-xr-x 3 root root 100 Aug 6 22:28 . drwxr-xr-x 20 root root 7780 Aug 6 22:28 .. drwxr-xr-x 2 root root 80 Aug 6 22:28 by-path crw-rw---- 1 root video 226, 0 Aug 6 22:28 card0 crw-rw---- 1 root render 226, 128 Aug 6 22:28 renderD128 [OK] Intel Quick Sync / GPU render device available (renderD128) [OK] Render device is accessible by current user [OK] sb-jellyfin-media is in the host's real render group (105)
Chris wrote:
That confirms it — doctor's hardware-transcoding section only checks Jellyfin's render-group membership right now, there's no Tdarr-specific check in it at all, so it genuinely can't tell you anything about Tdarr's device state. You've already ruled out everything on your end: the host has the device, Jellyfin picked it up after recreate, Tdarr still doesn't. That's a real product gap, not something a client-side step can close. I don't have a verified fix in hand to give you, so I won't guess — this is with Tom now with your full log trail attached. Thanks for the patience while it gets sorted.