容器版 Emby 调用核显硬解，Podman 容器保活记录

tags: NAS

@ 12/02/2026

容器版 Emby 调用核显硬解，Podman 容器保活记录

之前为了逃避 Linux 系统下。/dev/dri 的权限问题，我把 Emby 服务器搬到了 Windows 上，通过 SMB 挂载 NAS 文件夹来播放视频。再挂了 MediaWarp + Caddy 两套反向代理的情况下，这套方案的数据传输效率还是较低，于是我还是决定把 Emby 搬到 NAS 上部署。

还好，Emby 的配置文件是通用的，迁移之后只需要重新添加媒体库然后扫库就可以了。之前在 Windows 上扫库挺慢的，现在不走网络之后，扫库搜搜快。

Emby 无法调用核显的原因

来看看宿主机上的 /dev/dri 目录权限，可以看到是 660，也就是 root 用户和 video 用户组可读写。

> cd /dev/dri
> ll
总计 0
drwxr-xr-x   3 root root       120  2月12日 09:17 .
drwxr-xr-x  19 root root      3320  2月12日 09:17 ..
drwxr-xr-x   2 root root       100  2月12日 09:17 by-path
crw-rw----+  1 root video 226,   0  2月12日 09:34 card0
crw-rw----+  1 root video 226,   1  2月12日 09:34 card1
crw-rw----+  1 root video 226, 128  2月12日 09:34 renderD128

但 Emby 官方的 docker-compose.yml 使用 1000 用户和 100 用户组运行。

version: "2.3"
services:
  emby:
    image: emby/embyserver
    container_name: embyserver
    runtime: nvidia # Expose NVIDIA GPUs
    network_mode: host # Enable DLNA and Wake-on-Lan
    environment:
      - UID=1000 # The UID to run emby as (default: 2)
      - GID=100 # The GID to run emby as (default 2)
      - GIDLIST=100 # A comma-separated list of additional GIDs to run emby as (default: 2)
    volumes:
      - /path/to/programdata:/config # Configuration directory
      - /path/to/tvshows:/mnt/share1 # Media directory
      - /path/to/movies:/mnt/share2 # Media directory
    ports:
      - 8096:8096 # HTTP port
      - 8920:8920 # HTTPS port
    devices:
      - /dev/dri:/dev/dri # VAAPI/NVDEC/NVENC render nodes
      - /dev/vchiq:/dev/vchiq # MMAL/OMX on Raspberry Pi
    restart: on-failure

这导致容器内的 Emby 服务对 /dev/dri 没有读写权限。

如果在宿主机将 /dev/dri 权限修改为 666，也就是所有用户可读写，那么 Emby 就可以调用到核显了。

以 root 用户运行 Emby 容器（不推荐）

这与官方的设计思路相悖，非常不建议这么做。

安全性、隔离性都会有很大的问题。

`/dev/dri` 权限持久化（推荐）

你可以直接使用 chmod 666 -R /dev/dri 来临时修改权限，但重启后就会失效，比较麻烦。

解决方案是创建 udev 规则文件，这样内核在创建设备节点时会自动应用指定的权限。udev 规则路径通常是 /etc/udev/rules.d/规则文件命名通常是 99-xxx.rules 或 50-xxx.rules，udev 规则可以让权限在每次重启后自动生效。

创建 /etc/udev/rules.d/99-dri-permissions.rules 文件，添加以下内容：

SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0666"

允许所有用户访问渲染节点 /dev/dri/rederD128

SUBSYSTEM=="drm", KERNEL=="card*", GROUP="video", MODE="0660"

/dev/dri/card* 是显示设备，主要用于图形化功能，计算型服务用不上，可以不加

重载规则、立即应用：

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=drm

然后看看权限是否正常：

> cd /dev/dri
> ll
总计 0
drwxr-xr-x   3 root root       120  2月12日 09:17 .
drwxr-xr-x  19 root root      3320  2月12日 09:17 ..
drwxr-xr-x   2 root root       100  2月12日 09:17 by-path
crw-rw-rw-+  1 root video 226,   0  2月12日 09:34 card0
crw-rw-rw-+  1 root video 226,   1  2月12日 09:34 card1
crw-rw-rw-+  1 root video 226, 128  2月12日 09:34 renderD128

可以看到权限已经修改为所有用户可读写。

udev 规则是内核级别的设备管理，重启后依然有效，这是解决此类问题的"正统"做法，比容器层的各种 hack 更干净。

用户态 (rootless) Podman 容器保活

之前有写过这个问题，今天遇到了就再记录一下。

启用 Lingering

loginctl enable-linger sukipai