Docker image user

Channels DVR Server
#1

It looks like everything runs as root in the docker image by default. As a result, all of my recordings are owned by root. The linuxserver folks have docker images that let you specify PUID and PGID to have the containers create and use a user with those attributes internally so that files created/used by them in shared volumes will have the right ownership. Could something like that be adapted to channels-dvr?

Sadly, it’s not as simple as using the “–user” argument to Docker as that prevents the hardware transcoding feature from working as the device link is now inaccessible. It would need to create the user in the container, add that user to video, then start the app after switching to that user (via “USER username” in the Dockerfile).

#2

Ugh what a pain. Honestly, I regret making a docker container. You’d be much better off just using the Linux installer.

Anyway, one thing I could do is to fix the umask in the container. So even though everything is owned by root, atleast it will set permissions to allow other users to read/write the files.

Ideally we could support --user. Maybe there’s some way to convince docker to add that user to the dri device automatically?

#3

The umask idea could work (umask 0?) as a temporary fix, but the files would still technically be owned by root and require cleanup eventually.

The problem with “–user” is that the user given will generally not have permission to run adduser/addgroup to make that change, or to chown the video devices to something usable. Only root can, so the container has to start as root and manage the users afterwards. Again, linuxserver.io has a base image that does all this for you, too. It’s also using Alpine.

Well, one thing you could do is post the Dockerfile and that part of the project to Github (since it downloads all the binaries it needs, the core of it should be open, no?). I can muck around with it and send you a PR that fixes it.

#4

The Dockerfile is very simple, and I would like to keep it that way. But I guess if we can export the current user’s id/gid into the container when it’s created, and use those to setup the same user inside automatically, then that’s not a bad solution.

#5

Can you link the Dockerfile you were referring to?

#6

I was planning on poking around with it tonight. They have some other useful base images as well.

#7

So the simplest solution would probably be to modify your run.sh with some extra steps. I’ll link a script that the Yocto Project has used to drop root permissions to the same uid/gid combo as volume ownership of what’s passed in and then explain it.

The trick is to take your VOLUME and run stat on it to get the UID (%u) and GID (%g) and then create a user and switch to that user. Given how your container works I’d probably wire this up to the /shares directory.

1 Like
#8

You can ignore the 4 BUILD_UID and BUILD_GID lines after the stat call. Those are just there to massage things due to the way that Docker for Mac, Docker for Windows and docker-machine operate on non-Linux platforms. Since this container requires --net host neither of those 3 will work.

#9

Clever.

#10

Not to open this topic again, is it possible that this could be fixed?

1 Like
#11

I just made a docker for this, you can try it out if you want. It’s located at https://hub.docker.com/repository/docker/timstephens24/channels-dvr or if you want the code it’s on github at https://github.com/timstephens24/channels-dvr_docker.

1 Like
#12

Thank you, I'm moving to Truenas Scale once it is stable and this something I hadn't considered but I'm glad to see someone has made an easy fix.