Exposing a tty serial device requires privileged and doesn't work

reconbot commented 7 years ago

Expected behavior

That I can expose a tty dev device from my mac to a linux container by running.

$ docker run --rm -it -v `pwd`:/app --device /dev/tty.usbmodem1421 node bash

Actual behavior

$ docker run --rm -it -v `pwd`:/app --device /dev/tty.usbmodem1421 node bash
docker: Error response from daemon: linux runtime spec devices: error gathering device information while adding custom device "/dev/tty.usbmodem1421": lstat /dev/tty.usbmodem1421: no such file or directory.

I can work past this with --privileged but I don't see it in /dev/

$ docker run --rm -it -v `pwd`:/app --device /dev/tty.usbmodem1421 --privileged node bash
root@5a6a7f6b8e58:/# ls /dev/tty.*
ls: cannot access /dev/tty.*: No such file or directory

According to the docs on docker run I shouldn't need --privileged.

Information

Full output of the diagnostics from "Diagnose & Feedback" in the menu

Docker for Mac: version: 1.12.3-beta29.3 (619507e)
OS X: version 10.12.1 (build: 16B2555)
logs: /tmp/E9C6B44E-7492-484A-A6EF-EE5BE163959F/20161105-153323.tar.gz
[OK]     vmnetd
[OK]     dns
[OK]     driver.amd64-linux
[OK]     virtualization VT-X
[OK]     app
[OK]     moby
[OK]     system
[OK]     moby-syslog
[OK]     db
[OK]     env
[OK]     virtualization kern.hv_support
[OK]     slirp
[OK]     osxfs
[OK]     moby-console
[OK]     logs
[OK]     docker-cli
[OK]     menubar
[OK]     disk

Page URL if this is a docs issue or the name of a man page https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities

Steps to reproduce the behavior

hook up a tty serial device such as an Arduino, usb serial dongle, modem, cash drawer, etc to your mac
Run the commands above to expose it's /dev/tty.usbXXXX device to the docker image
Look for the device

justincormack commented 7 years ago

Unfortunately the Mac and Linux are running in different operating systems and cannot see the same devices. I think there are some existing issues, the way to implement it will differ for different device types, but it is not trivial.

larsks commented 7 years ago

Take a look at boot2docker/boot2docker#707 for some discussion on this topic.

reconbot commented 7 years ago

That all makes sense. Should we have some sort of error instead of a silent failure?

ijc commented 7 years ago

As @justincormack says this is (probably) possible but is likely to be non-trivial and is not currently a priority for us. I will file a wishlist ticket for this internally. Please :+1: the top comment if you are interested in this feature.

SiKing commented 7 years ago

@ijc25 Just curious: if I could convince my client to throw some money at this specifically, would that bump the priority?

ijc commented 7 years ago

@SiKing,

If someone (or someone's client's hired contractor) was to raise a PR against https://github.com/docker/hyperkit which added the necessary underlying support for USB device passthrough (i.e. causing the USB device to appear within the VM so the Linux usb tty class driver can be run on top) or adding some sort of serial/tty passthrough functionality (I'm not sure how that would look, but it might be a plausible approach) and work with the team to get that PR into an acceptable state to be merged into hyperkit then it ought then to be possible for d4m users to fudge things themselves to enable the passthrough locally, although it clearly wouldn't be a Supported d4m feature. Maybe d4m could supply a (most likely also unsupported) way to add hyperkit command line options to enable people to do this sort of thing more easily (at their own risk, get to keep both pieces if it breaks etc).

Another plausible alternative (and likely much simpler to achieve than passthrough if it works) might be to investigate libusb and/or usb over ip between your container and a daemon on the host, it's possible that might even be possible to setup without changes to either hyperkit or d4m (AIUI the wire protocol is intended to be portable, i.e. Mac talking to Linux is supposed to work, I don't know if that is really true though).

gw0 commented 7 years ago

One direction to achieve a workaround is with USB over IP for which a few commercial solutions exist. Nevertheless, the Docker VM that is based on Alpine Linux does not include all necessary kernel modules (vhci-hcd). I prepared a privileged Docker container to build Alpine Linux kernel modules and insert them in the kernel of the Docker VM. Does anyone know of a free and possibly open-source USB over IP solution that works on Mac and could be used with that?

WolfgangFahl commented 7 years ago

As @justincormack says this is (probably) possible but is likely to be non-trivial and is not currently a priority for us.

together with https://github.com/docker/for-mac/issues/77 and the dreadful (know limitations) in https://docs.docker.com/docker-for-mac/networking/ these are the showstoppers for using Docker on OSX from my point of view and the comment "not currently a priority for us" is not what I would have expected.

For a viable business I would expect that necessary / mandatory things to make virtualization useful should be high on the priority list. If I can not access simple devices like my usb devices or disk from a container what use can I make of container based virtualization? I'll have to still use VMWare and what is worse if i like docker I will have to go thru all kinds of tricks to make VMWare my host environment and docker work together.

When I first learned about docker I found the idea of having the option to run containers based on the same Dockerfile in windows, linux and Mac OS environments great. In the meantime I am more than disapppointed. Currently I think there is a complete failure of Docker to deliver on this idea in real world projects that need access to disks, network, graphics and devices.

gw0 commented 7 years ago

@WolfgangFahl Don't be so upset, the Docker Inc. has shown numerous times, that they do not care about the problems and use cases of small users. They even reject pretty well-designed pull requests that solve various issues.

lmapii commented 6 years ago

second this one. makes docker pretty much unusable for anything but web services ..

carusso commented 6 years ago

Basic networking and device pass-throughs from the host to the guest system are table stakes for virtualization. I was excited to start using the OSX Docker but quickly realized that it's just not ready yet.

docker-robott commented 6 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

alranel commented 6 years ago

/remove-lifecycle stale

hantuzun commented 6 years ago

I need to install Linux to my MacBook right now, just for this limitation. I'd be great if Docker Inc. would consider working on this issue.

docker-robott commented 5 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

jwise commented 5 years ago

I want this feature, too

/remove-lifecycle stale /lifecycle frozen

andreixk commented 5 years ago

/remove-lifecycle stale

rjhuijsman commented 5 years ago

+1 - this would make it so much easier to do development with external devices from a Docker-based development environment.

sajgonara commented 5 years ago

+1 - really need this issue to be fixed!!!

mrwonko commented 5 years ago

Working device passthrough would allow me to write onto ext4 SD cards on Mac, which would make Raspberry Pi development easier.

rubberduck203 commented 5 years ago

Example usecase: Using docker to standardize build tools while working on embedded software.

The build toolchain can all be standardized within the container and mounted for development with -v ${PWD}:/workingdir and then running make or whatever inside the container. This works great.

However, when it comes time to flash a microcontroller, or perform on target debugging, I have to fall back onto locally installed tools. Not exactly ideal.

lmapii commented 5 years ago

@rubberduck203 ran into the very same thing. also using a docker image as build environment and mapping USB devices into the container - but have to use docker-machine for that.

this is just the same as creating a linux virtual machine and starting docker there ... also virtualbox USB support is very volatile, using fixed version of both the client and boot2docker image since i ran into countless issues with USB devices not being recognized correctly.

rubberduck203 commented 5 years ago

@lmapii I came to the same conclusion. I'm trying to follow these instructions for exposing USB to docker on Mac, but I'm having a couple of issues.

VirtualBox sees the device as attached under Devices -> USB, but the guest OS doesn't list the port under /dev/tty*
docker-machine occasionally segfaults, leaves the guest OS running, but can't ever reconnect to it after that.

I would greatly appreciate it if you could tell me which versions of VBox, docker-machine, and boot2docker you're using.

After quite a bit of fiddling, I got it working with docker-machine. There’s a bug in several versions of VirtualBox that cause segfaults after adding usb filters. Updating to version 6.06 fixes the segfaults. You also can’t use USB 3.0 (usbxhci). You have to use USB 2.0 (usbehci). Switching to USB 2.0 is what made my device visible to the VM. (In retrospect, I should’ve caught this sooner, I had the same trouble with USB 3.0 in a Windows Guest on my Mojave host earlier this year.)

Keeps those things in mind and you can follow the instructions here as a work around. http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/

lmapii commented 5 years ago

@rubberduck203 good to know I'm not alone ;) sorry I'm a bit late. Version 6.x wasn't working for me, not even for a simple FTDI serial adapter. My current setup is

VirtualBox 5.2.22 r126460
Boot2Docker version 18.06.1-ce
docker-machine version 0.16.1, build cce350d7

rubberduck203 commented 5 years ago

Don’t be sorry @lmapii. FWIW, the latest of everything works if you want to upgrade. The big trick was upgrading to VirtualBox 6.06 and using USB 2.0.

https://dev.to/rubberduck/using-usb-with-docker-for-mac-3fdd

taylorhoward92 commented 5 years ago

With Docker and Arm announcing a partnership and with a lot of the focus being on a seamless developer experience for the Cloud, Edge and IoT, will this issue get addressed?

A lot of the content talks about being able to seamlessly develop for Arm architecture on x86_64 (with Docker Desktop) and then deploy to Arm. For a lot of developers working with Arm though, specifically in the IoT and Edge use cases, they will be working with external devices. So not being able to use device mapping into containers (unless using the above workaround) is a blocker to this seamless developer experience.

I've just tested the edge version (2.0.4.0) of Docker Desktop for Mac that has the new multi-arch features announced and the problem still persists.

thirtytwobits commented 5 years ago

This is a huge issue that makes docker unusable for embedded development on mac. "[this] is not currently a priority for us" is a shocking statement that makes me question the fundamental health of this project.

/remove-lifecycle stale

lmapii commented 5 years ago

@taylorhoward92 had a quick look at those IoT references - I'm afraid that won't help this issue: These projects all base on "web-technologies" and thus none of those devices will actually need to expose a physical interface. You'll most likely communicate with them using REST, MQTT or thelike, which may all happen via standard IP:port access.

jwise commented 5 years ago

@thirtytwobits Although I do have some health questions about Docker for other reasons, I don't think that it is necessarily the case that the fact that the priorities of a web and network infrastructure development tools company do not align with the priorities of embedded developers means that the project is unhealthy... they're just not an embedded company.

thirtytwobits commented 5 years ago

I don't think that it is necessarily the case that the fact that the priorities of a web and network infrastructure development tools company do not align with the priorities of embedded developers means that the project is unhealthy... they're just not an embedded company.

I guess my comment was a bit overly specific, sorry. Let me put it this way; I'm shocked that docker-for-mac is saying "feature parity with docker for linux is not a priority." This statement is what makes me question the health of the project (that and it's filesystem performance problems) and makes me wish the project was instead named "docker-ish for mac".

Certainly the marketing material should have a big red banner at the top saying "docker-for-mac is not fully compatible with docker on linux." They should also provide a feature availability matrix so you don't go down a rabbit hole building something that will ultimately fail when you try to deploy it in your organization.

lmapii commented 5 years ago

@rubberduck203 tried your versions but they won't work for me. They will recognize an FTDI cable, but, e.g., ATMEL's Xplained Boards (usually mounted as /dev/ACM0) won't work with the USB 2.0 setting. Back to 5.2.22 ...

Zjaaspoer commented 5 years ago

Wow, I'm pretty blown back by the lack of this functionality on a mac and the apparent lack of willingness to fix this issue, making the mac not a serious platform to use docker on.

I thought the whole idea of docker was to be platform agnostic?

TermanEmil commented 5 years ago

I really need this feature.

rubberduck203 commented 5 years ago

So, this fall Windows is releasing an update that should allow native Linux Docker containers on WSL. It might be time to make a switch if you need this. Either just run Linux or WSL2 on Windows.

The virtual box & docker machine combo works for some devices, but not all. As @Imappi pointed out, FTDI devices are confirmed to work.

Personally, I’ll be lobbying for a new PC this fall.

lmapii commented 5 years ago

Don't get your hopes up regarding WSL/Windows. I'm currently fighting with a Windows setup for a customer (still old WSL1). Windows Virtualilzation (underlying setup for Docker on Windows) does not support mapping USB devices at all. You might be interested in this thread.

So my fear is that even on Docker for Windows with WSL2 there might be the Virtualization service underneath, preventing all the goodness. I'm staying tuned though ;)

rokinsky commented 4 years ago

up

galvesribeiro commented 4 years ago

Hello folks,

This is a 3yrs old issue and still no solution?

gw0 commented 4 years ago

@galvesribeiro It can be done with a workaround. As someone already mentioned, one old workaround is on my page: http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/.

Otherwise (to repeat myself), don't be so upset, the Docker Inc. has shown numerous times, that they do not care about the problems and use cases of small users. They even reject pretty well-designed pull requests that solve various issues.

galvesribeiro commented 4 years ago

@gw0 I understand that but for me, that is mot an option to ise Virtual Boclx or any VM...

rimiti commented 4 years ago

Any update about this issue?

rimiti commented 4 years ago

I made some tests and this feature doesn't work on MacOS:

 (Darwin 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov  9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64)

But, on linux it works fine!

sbarcelona11 commented 4 years ago

Any update about this issue?

rimiti commented 4 years ago

Fyi, it doesn't work on MacOS, I switched to Linux to use this feature.

rfoltz commented 4 years ago

I would love to get this feature, to enable USB pass through in docker on Mac.I was just trying to setup a docker image for octoprint when you need to pass the 3D printer as a serial comm device and well looks like that's impossible at the moment.

justkash commented 4 years ago

Has anyone been able to get the workaround working with Docker-Machine? I followed what Christopher J. McClellan wrote about here, but I still receive the following error: docker: Error response from daemon: error gathering device information while adding custom device "/dev/tty.SLAB_USBtoUART": no such file or directory. even though the device does exist at /dev/tty.SLAB_USBtoUART.

specialistvlad commented 3 years ago

Any updates?

phaseOne commented 3 years ago

Support seems unlikely in hyperkit: https://github.com/moby/hyperkit/issues/149 X-reference: https://github.com/docker/for-mac/issues/5263 X-reference: https://github.com/docker/for-mac/issues/3110

YunEr-Wang commented 3 years ago

So this topic is a dead-end, and there is no way to connect the USB devices through docker when using Mac OS

peter-moran commented 3 years ago

Yes, and it is a shame. At my last company I tried finding tons of work arounds. One I did not test, but might work, is a USB over LAN solution like VirtualHere.

YunEr-Wang commented 3 years ago

So the best way is to use the VMware or virtual box to run a Linux OS, then, running the docker in the virtual system which needs powerful hardware, I think.

docker / for-mac