octoprint/octoprint image cannot connect to /dev/tty* about octoprint-docker

[LongLiveCHIEF]

This sounds like a host configuration issue. Let me explain.

docker containers don't have udev rules because containers don't do kernel things, and udevadm is most definitely a kernel process.

What you describe is typically caused when the host user that is running the docker/docker-compose commands not being part of the docker (or whatever group the docker-daemon uses), dialout and plugdev groups on the host machine.

When you run a container (such as the default octoprint image) as a non-root user, you either have to add privileges to your docker command, or use the --privileged flag and mount /dev:/dev.

Can you verify that your host user has the groups above, and if so, can you share your docker-compose file?

[LongLiveCHIEF]

What do you get when you run `ls /dev | grep tty`

…

On Sun, Aug 16, 2020, 7:46 PM Cabia Rangris ***@***.***> wrote: I am probably incorrect about fixing it with granting sudo though. It might vary from system to system — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZBLAKMOZRDTVV63TMNLJ3SBB4U3ANCNFSM4QBCTNOA> .

[cab404]

$ ls -l /dev | grep ttyUSB
crw-rw----  1 root dialout 188,   0 Aug 17 00:13 ttyUSB0

$ docker-compose exec octoprint bash -c 'ls -l /dev | grep ttyUSB'
crw-rw---- 1 root sudo 188, 0 Aug 16 23:57 ttyUSB0

I guess GID 27 just turned out to be sudo inside a container, that's why granting sudo is not a universal solution.
I won't be making a network accessible container with python2.7 inside privledged either)

My temporary solution was to grant sudo though.

[LongLiveCHIEF]

You may want to also consider trying out the new octoprint/octoprint:1.4.2-camera image variant we just published yesterday. It uses a different permissions model that we'll be bringing to the main image variants over the next few days.

[cab404]

docker-compose.yml

version: '3.7'

services:
  octoprint:
    image: octoprint/octoprint
    ports:
      - 5000:5000
    devices:
     - /dev/ttyUSB0:/dev/ttyUSB0
    volumes:
     - octoprint:/home/octoprint

volumes:
  octoprint:

groups of a user running docker-compose

users wheel dialout tor networkmanager docker plugdev avahi

docker image info:

REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
octoprint/octoprint   latest              c7e8e6e2fcf8        2 days ago          701MB

[cab404]

docker containers don't have udev rules because containers don't do kernel things, and udevadm is most definitely a kernel process.

I thought that udev doesn't work with guest groups (guest groups lose names in the host system, and mappings are implemented by docker)

[cab404]

I am probably wrong about fixing it by granting sudo though. It might vary from system to system

[cab404]

What do you get when you run ls /dev | grep tty
…
On Sun, Aug 16, 2020, 7:46 PM Cabia Rangris @.***> wrote: I am probably incorrect about fixing it with granting sudo though. It might vary from system to system — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZBLAKMOZRDTVV63TMNLJ3SBB4U3ANCNFSM4QBCTNOA .

In container:

tty
ttyUSB0

On host

tty
tty0..63
ttyS0..3
ttyUSB0

[cab404]

GID for ttyUSB0 is 27 in both.

[LongLiveCHIEF]

Yeah, each OS has slightly different udev rules for serial, character, and USB devices. Adding to the group inside the container does nothing really, it's all about the host.

[LongLiveCHIEF]

I will be including a section on setting up your host in the new docs, and this is a good reminder to put in a section around groups and permissions of the user running octoprint and those of the device attached to the container.

[LongLiveCHIEF]

Also, don't think that just because I closed this PR that your contributions aren't welcome. I just want to make sure we know what problems we're solving so we can consider what problems we might also be causing so that we can add those things to our testing (which is also coming soon). 😃

There is a dev-docker channel on the official OctoPrint Discord if you ever want to chat in real time, or consult on development.

[cab404]

I understand, really)

…

On August 17, 2020 4:46:41 PM GMT+03:00, Brian Vanderbusch ***@***.***> wrote: Also, don't think that just because I closed this PR that your contributions aren't welcome. I just want to make sure we know what problems we're solving so we can consider what problems we might also be causing so that we can add those things to our testing (which is also coming soon). :smiley: There is a `dev-docker` channel on the official [OctoPrint Discord](https://discord.octoprint.org) if you ever want to chat in real time, or consult on development. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #64 (comment)