Docker Community Forums

Share and learn in the Docker community.

How to expose host serial port to container correctly?

Dear All,

I am trying to expose host serial port to container. My system is Win10+Docker Desktop+Ubuntu1804.
It is Linux container.

My serial port on WIN10 is COM5, I suppose it should be ttyS5 in Linux. In order to confirm this, I use minicom to confirm I can receive correct data from ttyS5. Then I run below command:
docker run --name build --rm -ti --device /dev/ttyS5:/dev/ttyS1 -vpwd:/build vowstar/esp8266 /bin/bash


It shows error message:
Error response from daemon: error gathering device information while adding custom device "/dev/ttyS5": not a device node.

Anyone know how to fix this issue ?

Hi, is there anyone see this issue before ? or I post the wrong place ?

Hi All,

I change command a little bit as below:


Though I can enter the container, but ttyS5 is not a device node.

Anybody know how to fix it ?

I am also interested in something similar. Is there no solution available for it yet??

I suspect that you won’t succeed. Docker is a product of Linux philosophy, where “everything” is moulded into a file. All operations are file read/write calls. If you can transfer/tunnel a file read/write operation from A to B (e.g. from inside the container to the host), it makes no difference if the write really is configuring, say, the bit rate or parity of the physical serial port. All device APIs and drivers follow this philosophy.

In Windows (as well in the great majority of pre *nix OSes), devices are distinct concepts. At the API level you have got distinct calls for e.g. configuring the hardware, different from file read/write calls. A host/container interface made to transfer information through file system calls (only) has no facilities for non-filesystem device configuration calls.

There are two solutions to this - but as far as I know, neither is available as of todyay :frowning: -
Either, you can hope for the host/container interface in a future version to be extended, to include device management functions.

Or, you (or maybe “someone”) can write code stubs for moulding the device control functions to file system calls so that the the existing interface can be used as a tunneling mechanism. This requires a high level of expertise: In your case, you must learn exactly how the control functions are encoded when they come across the line from the Linux container. On the Windows side, you must write a service exposing a file (most likely a pipe) to the container interface in such a way that the interface believes it is a Linux style device file. The service must then interpret anything coming across this pipe and map it to Windows device calls. Status and data from the device must be mapped to the correct file write operations on the pipe going back to the container.

If the container is of Windows flavor, you must provide a device driver that captures all calls to the device, and marshall them into file system writes, and moulds data returned from the host, appearing as file system data, into device status reports for the container application.

Maybe this is not that difficult to do for a seasoned low level systems programming expert for a trivial demo example. To make a robust solution handling every possible call, every valid configuration, is a large undertaking.

For Linux, the mapping to file system calls is standardized (and has been for ages). To my knowledge, there is no similar standard mapping for Windows. Hopefully, the Linux standard can be used for that part of the functionality that is identical among the OSes, but I would be less than surprised if it turns out that Windows device operations in some details have a different semantics, or functionality not covered by the Linux encoding standard. Or, the Linux standard includes some funtionality with no equivalent in Windows. Before this can be offered as a general mechanism (so that you don’t have to install different drivers depending on which Docker image you want to run!), a standard must be established.

We have been waiting for this for USB devices for a whlle, but no solution is available, at least not yet. Several years ago, there was an open source project attempting to do it, using the network interface rather than the file system as a tunneling mechanism, but that activitiy seems to have died years ago. We hear rumours of something being worked on, but nothing is available for now.

I suspect that a USB solution has higher priority than the old COM port. Probably, if a USB solution is found, you can use a USB/RS232 adapter on the physical side, and map the serial port to a USB driver on the container (Linux) side. But you will probably have to wait a while before the USB solution is offered in the marketplace

It seems this is a very much requested feature. There is also a github issue on it:


In my case I have a piece of hardware developed from one lab that provides me with controllers and the driver is written only for Linux. My organization though has an infrastructure based on Windows. So my idea was to use the existing driver of the controller in a Linux container and only develop a handler/server software to run in it, communicating with our software on the windows side, instead of having to code the entire drivers for windows.
Still, if it is impossible, or very time-consuming, I will have to start on writing the API Driver under Windows.

Thank you all for the reply. As of today, you cannot access a COM device (or any other host device) from a Linux container running on Windows.