Last time I checked, Docker didn't have any means to give container access to host serial or USB port. Is there a trick which allows doing that?
There are a couple of options. First and foremost, as noted by @Mark below, Docker version 1.2.0 (released 2014/08) added the
--device flag that use can use to access USB devices without
docker run -t -i --device=/dev/ttyUSB0 ubuntu bash
Alternatively, assuming your USB device is available with drivers working, etc. on the host in
/dev/bus/usb, you can mount this in the container using privileged mode and the volumes option. For example:
docker run -t -i --privileged -v /dev/bus/usb:/dev/bus/usb ubuntu bash
Note that as the name implies,
--privileged is insecure and should be handled with care.
With current versions of Docker, you can use the
--device flag to achieve what you want, without needing to give access to all USB devices.
For example, if you wanted to make only
/dev/ttyUSB0 accessible within your Docker container, you could do something like:
docker run -t -i --device=/dev/ttyUSB0 ubuntu bash
I wanted to extend the answers already given to include support for dynamically connected devices that aren't captured with
/dev/bus/usb and how to get this working when using a Windows host along with the boot2docker VM.
If you are working with Windows, you'll need to add any USB rules for devices that you want Docker to access within the VirtualBox manager. To do this you can stop the VM by running:
host:~$ docker-machine stop default
Open the VirtualBox Manager and add USB support with filters as required.
Start the boot2docker VM:
host:~$ docker-machine start default
Since the USB devices are connected to the boot2docker VM, the commands need to be run from that machine. Open up a terminal with the VM and run the docker run command:
host:~$ docker-machine ssh [email protected]:~$ docker run -it --privileged ubuntu bash
Note, when the command is run like this, then only previously connected USB devices will be captures. The volumes flag is only required if you want this to work with devices connected after the container is started. In that case, you can use:
[email protected]:~$ docker run -it --privileged -v /dev:/dev ubuntu bash
Note, I had to use
/dev instead of
/dev/bus/usb in some cases to capture a device like
/dev/sg2. I can only assume the same would be true for devices like
The docker run commands will work with a Linux host as well.
--device works until your USB device gets unplugged/replugged and then it stops working. You have to use cgroup devices.allow get around it.
You could just use
-v /dev:/dev but that's unsafe as it maps all the devices from your host into the container, including raw disk devices and so forth. Basically this allows the container to gain root on the host, which is usually not what you want.
Using the cgroups approach is better in that respect and works on devices that get added after the container as started.
See details here: Accessing USB Devices In Docker without using --privileged
It's a bit hard to paste, but in a nutshell, you need to get the major number for your character device and send that to cgroup:
189 is the major number of /dev/ttyUSB*, which you can get with 'ls -l'. It may be different on your system than on mine:
[email protected]:~# echo 'c 189:* rwm' > /sys/fs/cgroup/devices/docker/$A*/devices.allow (A contains the docker containerID)
Then start your container like this:
docker run -v /dev/bus:/dev/bus:ro -v /dev/serial:/dev/serial:ro -i -t --entrypoint /bin/bash debian:amd64
without doing this, any newly plugged or rebooting device after the container started, will get a new bus ID and will not be allowed access in the container.
With latest versions of docker, this is enough:
docker run -ti --privileged ubuntu bash
It will give access to all system resources (in /dev for instance)
Another option is to adjust udev, which controls how devices are mounted and with what privileges. Useful to allow non-root access to serial devices. If you have permanently attached devices, the
--device option is the best way to go. If you have ephemeral devices, here's what I've been using:
1. Set udev rule
By default, serial devices are mounted so that only root users can access the device. We need to add a udev rule to make them readable by non-root users.
Create a file named /etc/udev/rules.d/99-serial.rules. Add the following line to that file:
MODE="0666" will give all users read/write (but not execute) permissions to your ttyUSB devices. This is the most permissive option, and you may want to restrict this further depending on your security requirements. You can read up on udev to learn more about controlling what happens when a device is plugged into a Linux gateway.
2. Mount in /dev folder from host to container
Serial devices are often ephemeral (can be plugged and unplugged at any time). Because of this, we can’t mount in the direct device or even the /dev/serial folder, because those can disappear when things are unplugged. Even if you plug them back in and the device shows up again, it’s technically a different file than what was mounted in, so Docker won’t see it. For this reason, we mount the entire /dev folder from the host to the container. You can do this by adding the following volume command to your Docker run command:
If your device is permanently attached, then using the --device option or a more specific volume mount is likely a better option from a security perspective.
3. Run container in privileged mode
If you did not use the --device option and mounted in the entire /dev folder, you will be required to run the container is privileged mode (I'm going to check out the cgroup stuff mentioned above to see if this can be removed). You can do this by adding the following to your Docker run command:
4. Access device from the /dev/serial/by-id folder
If your device can be plugged and unplugged, Linux does not guarantee it will always be mounted at the same ttyUSBxxx location (especially if you have multiple devices). Fortunately, Linux will make a symlink automatically to the device in the /dev/serial/by-id folder. The file in this folder will always be named the same.
This is the quick rundown, I have a blog article that goes into more details.