for-mac
for-mac copied to clipboard
docker
Exposing a tty serial device requires privileged and doesn't work
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.usbXXXXdevice to the docker image - Look for the device
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.
Take a look at boot2docker/boot2docker#707 for some discussion on this topic.
That all makes sense. Should we have some sort of error instead of a silent failure?
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.
@ijc25 Just curious: if I could convince my client to throw some money at this specifically, would that bump the priority?
@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).
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?
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.
@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.
second this one. makes docker pretty much unusable for anything but web services ..
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.
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
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.
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
+1 - this would make it so much easier to do development with external devices from a Docker-based development environment.
Working device passthrough would allow me to write onto ext4 SD cards on Mac, which would make Raspberry Pi development easier.
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.
@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.
@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-machineoccasionally 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/
@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
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
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.
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
@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.
@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.
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.