--gpu and --alsa options don't respect host ownership of devices in /dev/snd and /dev/dri

[ehough]

I'm enjoying the use of x11docker to run Kodi and, with the exception of a few kinks that need to be ironed out, it's been working great for the past few months.

This week, my sound stopped working and the video suddenly looked choppy. In the course of debugging, I found that the problem was related to the container's permissions of /dev/snd/* and /dev/dri/*. The good news is that I believe I found a simple fix that you might want to consider.

On my host, the items in /dev/snd and /dev/dri have group ownership of audio and video. I think that's pretty standard for (at least) Debian-based distros..

$ ls -alh /dev/snd /dev/dri
/dev/dri:
total 0
drwxr-xr-x  2 root root       100 Mar  1 20:04 .
drwxr-xr-x 19 root root      3.3K Mar  1 20:04 ..
crw-rw----  1 root video 226,   0 Mar  1 20:25 card0
crw-rw----  1 root video 226,  64 Mar  1 20:04 controlD64
crw-rw----  1 root video 226, 128 Mar  1 20:04 renderD128

/dev/snd:
total 0
drwxr-xr-x  3 root root      300 Mar  1 20:04 .
drwxr-xr-x 19 root root     3.3K Mar  1 20:04 ..
drwxr-xr-x  2 root root       60 Mar  1 20:04 by-path
crw-rw----  1 root audio 116,  2 Mar  1 20:04 controlC0
crw-rw----  1 root audio 116, 10 Mar  1 20:04 hwC0D0
crw-rw----  1 root audio 116, 11 Mar  1 20:04 hwC0D2
crw-rw----  1 root audio 116,  4 Mar  1 20:04 pcmC0D0c
crw-rw----  1 root audio 116,  3 Mar  1 21:58 pcmC0D0p
crw-rw----  1 root audio 116,  5 Mar  1 20:04 pcmC0D1p
crw-rw----  1 root audio 116,  6 Mar  1 20:04 pcmC0D2c
crw-rw----  1 root audio 116,  7 Mar  1 21:59 pcmC0D3p
crw-rw----  1 root audio 116,  8 Mar  1 20:04 pcmC0D7p
crw-rw----  1 root audio 116,  9 Mar  1 20:04 pcmC0D8p
crw-rw----  1 root audio 116,  1 Mar  1 20:04 seq
crw-rw----  1 root audio 116, 33 Mar  1 20:04 timer

But in the container, if you inspect those same directories, you'll see that the items have root:root ownership:

$ docker run -it --rm --device /dev/snd:/dev/snd --device /dev/dri:/dev/dri ubuntu 
root@1a34f22340ad:/# ls -alh /dev/snd /dev/dri
/dev/dri:
total 0
drwxr-xr-x 2 root root      100 Mar  2 06:12 .
drwxr-xr-x 7 root root      400 Mar  2 06:12 ..
crw-rw---- 1 root root 226,   0 Mar  2 06:12 card0
crw-rw---- 1 root root 226,  64 Mar  2 06:12 controlD64
crw-rw---- 1 root root 226, 128 Mar  2 06:12 renderD128

/dev/snd:
total 0
drwxr-xr-x 2 root root     280 Mar  2 06:12 .
drwxr-xr-x 7 root root     400 Mar  2 06:12 ..
crw-rw---- 1 root root 116,  2 Mar  2 06:12 controlC0
crw-rw---- 1 root root 116, 10 Mar  2 06:12 hwC0D0
crw-rw---- 1 root root 116, 11 Mar  2 06:12 hwC0D2
crw-rw---- 1 root root 116,  4 Mar  2 06:12 pcmC0D0c
crw-rw---- 1 root root 116,  3 Mar  2 06:12 pcmC0D0p
crw-rw---- 1 root root 116,  5 Mar  2 06:12 pcmC0D1p
crw-rw---- 1 root root 116,  6 Mar  2 06:12 pcmC0D2c
crw-rw---- 1 root root 116,  7 Mar  2 06:12 pcmC0D3p
crw-rw---- 1 root root 116,  8 Mar  2 06:12 pcmC0D7p
crw-rw---- 1 root root 116,  9 Mar  2 06:12 pcmC0D8p
crw-rw---- 1 root root 116,  1 Mar  2 06:12 seq
crw-rw---- 1 root root 116, 33 Mar  2 06:12 timer

The result is that the processes started by x11docker, which are non-root of course, can't read/write to these devices. In my case, that results in Kodi not being able to utilize hardware video acceleration and output any sound.

So for some reason --device makes the respective devices root:root in the container, but we need it to respect at least the group ownership. I found this comment which suggested adding -v in addition to --device. I tried that and boom:

docker run -it --rm --device /dev/snd:/dev/snd --device /dev/dri:/dev/dri -v /dev/dri:/dev/dri -v /dev/snd:/dev/snd ubuntu 
root@9c56a28761a6:/# ls -alh /dev/snd /dev/dri
/dev/dri:
total 0
drwxr-xr-x 2 root root       100 Mar  2 04:04 .
drwxr-xr-x 7 root root       400 Mar  2 06:23 ..
crw-rw---- 1 root video 226,   0 Mar  2 04:25 card0
crw-rw---- 1 root video 226,  64 Mar  2 04:04 controlD64
crw-rw---- 1 root video 226, 128 Mar  2 04:04 renderD128

/dev/snd:
total 0
drwxr-xr-x 3 root root      300 Mar  2 04:04 .
drwxr-xr-x 7 root root      400 Mar  2 06:23 ..
drwxr-xr-x 2 root root       60 Mar  2 04:04 by-path
crw-rw---- 1 root audio 116,  2 Mar  2 04:04 controlC0
crw-rw---- 1 root audio 116, 10 Mar  2 04:04 hwC0D0
crw-rw---- 1 root audio 116, 11 Mar  2 04:04 hwC0D2
crw-rw---- 1 root audio 116,  4 Mar  2 04:04 pcmC0D0c
crw-rw---- 1 root audio 116,  3 Mar  2 05:58 pcmC0D0p
crw-rw---- 1 root audio 116,  5 Mar  2 04:04 pcmC0D1p
crw-rw---- 1 root audio 116,  6 Mar  2 04:04 pcmC0D2c
crw-rw---- 1 root audio 116,  7 Mar  2 06:20 pcmC0D3p
crw-rw---- 1 root audio 116,  8 Mar  2 04:04 pcmC0D7p
crw-rw---- 1 root audio 116,  9 Mar  2 04:04 pcmC0D8p
crw-rw---- 1 root audio 116,  1 Mar  2 04:04 seq
crw-rw---- 1 root audio 116, 33 Mar  2 04:04 timer

I don't know if that's a bug in Docker, or if there's a "better" way to get Docker to respect permissions of raw devices. Nor do I know why I'm only now seeing these issues. But I do know that adding -v /dev/snd:/dev/snd and -v /dev/dri:/dev/dri fixes things for me.

Here's a copy of my latest x11docker.log. In the "Created docker command" area you can see that I added my workaround.

Thoughts?

[mviereck]

Thank you!
Quite strange situation. --gpu works fine here even without your patch, tested with debian 9 on host and in image. Though, I can confirm the mismatching group ids.

Depending on the container system there may be different ways to allow access to /dev/dri and /dev/snd.

The docker bug report you've linked is a few years old; maybe it has been fixed and has a regression now. There has been a docker update a few days ago.

On the x11docker side I've made a related change in V3.9.2.3, but that should not have effect here. It just --group-add's the GIDs of video and audio instead of their name and reviews /etc/group in container to verify it matches the host entries. (Some systems have different GID's for video and audio than others).

[ehough]

Thank you. x11docker has been incredibly useful for me and I think it has huge potential as more people learn about your work. Happy to contribute a little.

maybe it has been fixed and has a regression now. There has been a docker update a few days ago.

I remember updating Docker on my host a few days ago but didn't connect the dots that it might have been related. Sure enough, it's a regression reported here with a corresponding PR here. Presumably that will make it into the next Docker release.

I'm not sure if there are any negative side effects of leaving my patch in x11docker. I haven't noticed any problems. At the very least, folks running x11docker with Docker 17.12.1 won't run into problems.

p.s. I'm close to publishing details of how I run Kodi with x11docker. Once that's ready, I'll submit another PR for you to consider listing it with the other examples.

[mviereck]

p.s. I'm close to publishing details of how I run Kodi with x11docker. Once that's ready, I'll submit another PR for you to consider listing it with the other examples.

I am willingly to add a kodi example in the Readme. Do you want to create an automated build on docker hub?

I have seen you shared /etc/localtime with container. Good catch; I have implemented that in x11docker now.

Why do you add capability SYS_NICE?

[ehough]

I am willingly to add a kodi example in the Readme. Do you want to create an automated build on docker hub?

Cool! Yes, I'll create an automated build on Docker Hub + a repo. I'm still having a few audio/video quirks that I'm working out. e.g. sometimes I'll get no video after leaving it sit for a few days. Once that's done I'll publish my work and let you know. I just want to feel a little more confident about my setup before I share it.

Why do you add capability SYS_NICE?

Just personal preference. I run a bunch of local services on that box (file sharing, DNS, Kerberos, etc) and Kodi is non-essential so I nice it down a little.

[mviereck]

The docker bug is fixed in current Docker version 18.03.1-ce.
I'll leave your fix with --volume additional to --device for some time (some month?) until hopefully everyone has made an update.