Posted on by richay

Intel Arc A310 Hardware Transcoding in a Proxmox LXC

Status: CURRENT
Last reviewed: 31 August 2026
Applies to: Proxmox VE 8.2+/9, unprivileged LXC, Intel Arc A310 and Plex hardware transcoding

This is how I pass my Intel Arc A310 through to an unprivileged Plex LXC on Proxmox. Current Proxmox can pass the render device straight into the container, so the old cgroup/idmap/bind-mount witchcraft is no longer required.

I use an Intel Arc A310 in my Proxmox box purely because it is a tiny little transcoding monster for Plex.

Plex itself runs inside an unprivileged LXC, with Plex running in Docker inside that container. Sounds like three layers of bullshit, but the GPU path is actually pretty simple:

Intel Arc A310
      ↓
Proxmox host
      ↓
/dev/dri/renderD128
      ↓
unprivileged Plex LXC
      ↓
Docker
      ↓
Plex
      ↓
hardware transcode :)


The important device for video transcoding is normally the render node. Plex on Linux uses Intel VAAPI for hardware decode/encode, so we don’t need to PCI-passthrough the whole GPU like we would with a VM.

1. Make sure Proxmox can see the Arc

On the Proxmox host:

lspci -k | grep -EA3 'VGA|3D|Display'

ls -la /dev/dri
ls -la /dev/dri/by-path


On my machine the Arc currently appears as:

/dev/dri/card1
/dev/dri/renderD128


Your cardX number can be different, especially if the CPU also has integrated graphics.

The by-path directory is handy for confirming which DRM device belongs to which PCI GPU before blindly passing through the first thing called renderD128.

Intel’s current Linux guidance says modern Ubuntu distributions have Arc graphics support in the normal distro/kernel stack; you generally don’t need to bolt on one of Intel’s old custom driver repositories just to make the GPU exist. The Intel Media Driver/VAAPI userspace components may still be needed by applications that use VAAPI.

2. Pass the GPU device into the LXC

This is the bit that has become much nicer in modern Proxmox.

Shut the Plex LXC down, then go to:

Plex LXC
→ Resources
→ Add
→ Device Passthrough


Add the render device:

/dev/dri/renderD128


I also pass the matching card device through because it makes GPU diagnostics inside the container easier:

/dev/dri/card1


Proxmox’s current pct tooling exposes these as normal dev0, dev1 device entries. No manual lxc.cgroup2.devices.allow, no hand-written bind mount, no sacrificing a goat to UID mapping.

The CLI equivalent looks like:

pct set 103 -dev0 /dev/dri/renderD128
pct set 103 -dev1 /dev/dri/card1


Then:

pct config 103


You should see the device entries in the container configuration.

3. Start the LXC and check /dev/dri

pct start 103
pct enter 103
ls -la /dev/dri


On my Plex LXC I currently have:

card1
renderD128


If the devices aren’t there, stop. Plex isn’t going to magically discover a GPU that the LXC cannot see.

4. Fix access to the render device

Inside my container the useful groups are:

video:x:44
render:x:105


My Plex user is a member of both:

getent group video
getent group render


For my current setup I get:

video:x:44:plex
render:x:105:root,plex,richay


If Plex isn’t in the groups, add it:

sudo usermod -aG video plex
sudo usermod -aG render plex


Then restart the service/container so the new group membership actually applies.

Quick permission test: Proxmox device passthrough also lets you assign a mode/GID to the device. Using something like mode=0666 can be useful for proving that a failure is purely permissions, but I wouldn’t leave the GPU world-writable just because it made the red error disappear. Fix the group access afterwards.

5. Pass /dev/dri into the Plex Docker container

Now the LXC has the GPU, Docker needs it too.

In my Plex Compose stack:

services:
  plex:
    devices:
      - /dev/dri:/dev/dri


Then recreate Plex:

docker compose up -d
docker exec plex ls -la /dev/dri


If Docker can see renderD128, we’ve successfully pushed the GPU through both layers:

Proxmox host     ✓
LXC              ✓
Docker container ✓
Plex             ...your turn mate


6. Enable hardware transcoding in Plex

In Plex Web:

Settings
→ Server
→ Transcoder
→ Show Advanced

✓ Use hardware acceleration when available
✓ Use hardware-accelerated video encoding


Plex currently requires Plex Pass for normal hardware-accelerated streaming.

If more than one GPU is available, Plex also has a Hardware transcoding device selector. I explicitly select the Intel Arc rather than leaving it on Auto when I want to be absolutely sure which device Plex is using.

Plex’s current Linux transcoder uses Intel VAAPI for both hardware decode and hardware encode when supported.

7. Actually prove it is working

Seeing the GPU in /dev/dri is nice. It does not prove Plex is using it.

Start playing a video, then deliberately force a transcode by dropping the playback quality to something like 480p.

Open the Plex Dashboard and expand the playback details.

What I want to see is:

Video
Transcode (hw)


Plex’s own documentation specifically says the (hw) marker is the way to confirm hardware acceleration is being used.

If it just says Transcode with no (hw), congratulations: your expensive little GPU is currently decorative.

Watching the Arc work from the Proxmox host

I also like watching the GPU directly while forcing a transcode.

Install Intel’s GPU tools on the Proxmox host if you don’t already have them:

apt update
apt install intel-gpu-tools


Then:

intel_gpu_top


Force a Plex transcode and you should see the media/video engines wake up.

This is my favourite test because the Plex Dashboard can say whatever lovely thing it wants — watching the GPU actually do work removes the guesswork.

Optional VAAPI test inside the LXC

If Plex still refuses to use the GPU, test VAAPI independently of Plex.

apt update
apt install vainfo intel-media-va-driver-non-free

vainfo --display drm --device /dev/dri/renderD128


If vainfo can enumerate the Arc’s decode/encode capabilities, the Linux/VAAPI path is alive and the problem is further up the stack.

Don’t install random Intel driver repositories just because an old guide tells you to. Intel’s current Linux guidance says modern Ubuntu releases include Arc graphics support in the normal distribution stack. Add extra driver packages only when your actual distro/application needs them.

The old way can stay dead

Older Proxmox LXC GPU guides tended to involve things like:

lxc.cgroup2.devices.allow = c 226:* rwm
lxc.mount.entry = /dev/dri ...
subuid
subgid
custom idmaps
chmod
prayer


Some of that was necessary at the time.

For a current Proxmox LXC, native device passthrough is dramatically cleaner. Proxmox’s current pct configuration supports passing a host device directly into a container and assigning the device node’s UID, GID and access mode if needed.

Use the modern feature before manually rebuilding the old plumbing underneath it.

My final setup

Intel Arc A310
    ↓
Proxmox device passthrough
    ↓
/dev/dri/renderD128
    ↓
Plex unprivileged LXC
    ↓
Docker /dev/dri mapping
    ↓
Plex VAAPI
    ↓
Transcode (hw)
    ↓
CPU gets to stop screaming :)


That’s really all there is to it now.

The Arc A310 doesn’t need the whole VM PCI-passthrough treatment for this job. Let the Proxmox host own the GPU, hand the render device to the LXC, hand it through Docker, and let Plex chew on it.

Much cleaner than the old janky config I eventually deleted — and considerably easier to remember the next time I inevitably break it myself 😀

References

Leave a Reply

Your email address will not be published. Required fields are marked *