Jump to content

Docker


Luke

Recommended Posts

Edrock200
On 11/12/2014 at 10:08 PM, Luke said:

It is already up to date with the recent stable release.

4.8.1 is the latest stable, but it's not up on the official repo

Link to comment
Share on other sites

zer0ish
1 minute ago, Edrock200 said:

4.8.1 is the latest stable, but it's not up on the official repo

Showed for me and I have that version currently. 

image.thumb.png.0c9d3b3ca34407097a76fd30b82dd8f9.png

  • Thanks 1
Link to comment
Share on other sites

Edrock200
23 minutes ago, zer0ish said:

Showed for me and I have that version currently. 

image.thumb.png.0c9d3b3ca34407097a76fd30b82dd8f9.png

Yep, you are 100% right. Didn't catch a hard coded version in my deployment, which is why watchtower wasn't pulling. My bad.

Link to comment
Share on other sites

  • 2 weeks later...
darkassassin07

Fairly recently switched to docker and am pretty happy with it so far.

 

I originally had my emby container run by the root user, but after switching it to be run by a different user, I now get the error "Error response from daemon: unknown or invalid runtime name: nvidia"

How do I give a non root user access to the nvidea daemon/runtime for use in docker?

 

Nvidia drivers are installed as well as nvidia-container-toolkit. Hardware transcoding is functioning, as long as it was root that ran the docker compose up command...

 

 

Running Debian 12

Link to comment
Share on other sites

darkassassin07
version: "2.3"
services:
  embybeta:
    image: emby/embyserver:beta
    container_name: embybeta
    runtime: nvidia # Expose NVIDIA GPUs
    environment:
      - UID=1000 # The UID to run emby as (default: 2)
      - GID=1000 # The GID to run emby as (default 2)
#      - UID=0 # The UID to run emby as (default: 2)
#      - GID=0 # The GID to run emby as (default 2)
      - GIDLIST=100 # A comma-separated list of additional GIDs to run emby as (default: 2)
    volumes:
      - /srv/embybeta/programdata:/config # Configuration directory
      - /mnt/Drobo/Media:/Media:ro # Media directory
      - /mnt/Backups/Emby_Beta:/Backups #backup directory
      - /mnt/Cache/Emby_Cache_Beta:/Cache #cache
      - /mnt/Cache/Transcoding_Temp_Beta:/Transcoding_temp #transcoding directory
#    ports:
#      - 8096:8096 # HTTP port
    devices:
      - /dev/dri:/dev/dri # VAAPI/NVDEC/NVENC render nodes
    networks:
      - arr
    restart: unless-stopped
networks:
  arr:
    external: true

 

 

 

If I leave the 'runtime' and 'devices' sections un-commented and run as non-root I get the above error. Comment them out and it starts, but no HW Acceleration.

 

Running the same compose via sudo runs fine; but then it's not displayed/managed in docker desktop and seems to use seprate 'arr' networks internally. (I have an nginx container handling all the host network>docker connections, through the Internal 'arr' network)

Edited by darkassassin07
Link to comment
Share on other sites

Q-Droid

Hmmm. That would point to access and/or visibility. I guess the question is whether the problem is access to the render devices for UID/GID/GIDLIST, which by the way don't look quite right to me. Or visibilty of the nvidia runtime for the UID/GID 1000.

 

Link to comment
Share on other sites

darkassassin07

UID/GID 1000 is my main user. I've removed GIDLIST from my compose.

 

 

I'm not sure how to troubleshoot visibility issues between that id and the runtime.

 

Linux is relatively new beast for me. Trying to learn and explore. I appreciate the help though :)

Link to comment
Share on other sites

Q-Droid

In a typical setup you use the GIDLIST to include access to the video/graphics render devices (/dev/dri). It's a list of the IDs for the groups, usually video and render. But I don't know what is needed to make sure the emby user (or whichever user ID is 1000 on your system) is able to use/reference the nvidia runtime. So you can start with the GIDLIST but more might be needed.

There's also this thread which you might have seen already and is a bit long...

 

Edited by Q-Droid
Link to comment
Share on other sites

darkassassin07

With some more digging I've found there's separate daemon configs for root/non-root docker. Adding the Nvidia runtime config to the non-root version (via docker desktop, I'm not sure where that is stored on disk), now the non-root containers can see the Nvidia runtime and stopped reporting that error.

 

Now I'm getting the error:  "Error response from daemon: error gathering device information while adding custom device "/dev/dri": no such file or directory"

Trying to figure out the required permissions, but linux permissions have always confused me :/

 

Here's  "ls -n /dev/dri"
total 0
drwxr-xr-x  2 0   0       80 Mar  3 13:40 by-path
crw-rw----+ 1 0  44 226,   0 Mar  3 13:40 card0
crw-rw----+ 1 0 105 226, 128 Mar  3 13:40 renderD128

 

I've added "- GIDLIST=1000,226" to my compose, but that hasn''t helped.

Link to comment
Share on other sites

Q-Droid
24 minutes ago, darkassassin07 said:

Here's  "ls -n /dev/dri"
total 0
drwxr-xr-x  2 0   0       80 Mar  3 13:40 by-path
crw-rw----+ 1 0  44 226,   0 Mar  3 13:40 card0
crw-rw----+ 1 0 105 226, 128 Mar  3 13:40 renderD128

That should be GIDLIST=44,105.

4 hours ago, darkassassin07 said:
devices:
      - /dev/dri:/dev/dri # VAAPI/NVDEC/NVENC render nodes

The devices entry in the compose you posted looks correct. 

 

Link to comment
Share on other sites

darkassassin07

Huh, I thought those were 2 groups: card0 in 44+226, renderD128 in 105+226.

 

Anyway, added 226,44,and105 to the list, but same result:

 

"Error response from daemon: error gathering device information while adding custom device "/dev/dri": no such file or directory"

 

The /dev/ and /dev/dri/ folders both have "drwxr-xr-x" permissions, so I don't understand why it's not visible.

Edited by darkassassin07
Link to comment
Share on other sites

Q-Droid

No, if you run ls -l you'll see one device is owned by root:video and the other root:render. 226 is the device number.

Have you looked through the docker Nvidia HW thread? The answer is very likely to be in there somewhere. I wish I could be more help but I don't use Nvidia GPU so no way for me to try things.

Link to comment
Share on other sites

darkassassin07

Well... I think I know what the issue is: docker desktop, you're required to specify what folders are allowed to be shared with containers, as well as actually specify the mounts in the compose file. I'd added everything I needed except /dev/dri/....

 

Thing is now I suddenly can't run ANY containers from non-root. Every single container I try, including the 'hello-world' test docker container, just infinitely says 'Container <name> Starting' upon running 'docker compose up -d' and then just continuously counts up. Left it for over 1k seconds, none will start. As they never start, I don't get errors or exit codes.

 

Every compose I've tried with sudo added, runs fine.

 

I don't understand what's changed. I've done nothing but modify compose files and run docker compose up/down.

 

 

 

Edit:

Well, re-installed docker desktop and am back to being able to run containers as non-root; but adding /dev/dri to the list of allowed directories hasn't fixed my original issue.

Edited by darkassassin07
Link to comment
Share on other sites

Q-Droid

Sounds like you have a few things going on that weren't clear before in the thread.

1. Running compose as root vs non-root. I usually run the administrative stuff as root (equiv to sudo). When the containers are created they still run with the given UID/PID unless none are given then it's root. Or more accurately the dockerd/containerd runtime user.

2. Docker Desktop vs Docker Engine. There are differences and likely config needed for Desktop to behave more like Engine on bare metal.

So when you run as root vs non-root do you mean the CLI/UI for config and compose or setting the UID/PUID/GID/PGID for the containers to 0? If it's the first then I think you're fine. Some containers need to be root, such as reverse proxies if you're running on ports below 1024.

Link to comment
Share on other sites

darkassassin07

I'm starting to realize #2 is a big factor to my troubles. When I'm talking about running as non root, I literally just mean running the docker compose command without sudo, which should be exactly the same, given the user is in the 'docker' user group; running the container under the existing root docker engine as whatever uid/gid given in the command/compose.

 

Because I have docker desktop installed though, it runs a second docker engine under the users namespace instead of the root one. That engine is more isolated and needs more setup work than I expected (I didn't even realize they were two engines).

 

I think I'm going to purge docker, setup just the standard engine without desktop; and see how that goes. I'm creating more problems than I need. Docker Desktop for Linux is fairly new afaik and doesn't have much documentation/help.

Edited by darkassassin07
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...