容器版 Emby 调用核显硬解，Podman 容器保活记录
categories: 技术 tags: NAS容器版 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