Cannot access mounted pts device inside container

[codeaholics]

• This is a bug report
• This is a feature request
• I searched existing issues before opening this one

Expected behavior

Mounting a pts device with --device should make it accessible within the container.

Actual behavior

The device appears, but I get EIO when trying to access it.

Steps to reproduce the behavior

I am using socat to bring a remote serial port to my server over the LAN. socat creates pts devices.

On the physical machine:

root@server:~# ls -l /dev/pts/1
crw--w---- 1 root tty 136, 1 Aug  3 20:54 /dev/pts/1
root@server:~# cat /dev/pts/1
[...output from remote serial device...]

Start a container:

docker run -ti --device=/dev/pts/1:/dev/hostpts ubuntu:17.04 /bin/bash

Now, inside the container:

root@689d0696b167:/# ls -l /dev/hostpts
crw--w---- 1 root tty 136, 1 Aug  3 20:02 /dev/hostpts
root@689d0696b167:/# cat /dev/hostpts
cat: /dev/hostpts: Input/output error

Trying with /dev/null instead of a pts appears to work fine:

root@server:~# docker run -ti --device=/dev/null:/dev/hostnull ubuntu:17.04 /bin/bash
root@2b75680ed7a9:/# ls -l /dev/hostnull
crw-rw-rw- 1 root root 1, 3 Aug  3 20:03 /dev/hostnull
root@2b75680ed7a9:/# cat /dev/hostnull
root@2b75680ed7a9:/#

Output of docker version:

Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:18:10 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:17:03 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

Containers: 21
 Running: 3
 Paused: 0
 Stopped: 18
Images: 56
Server Version: 17.06.0-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 78
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.10.0-26-generic
Operating System: Ubuntu 17.04
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.55GiB
Name: server
ID: MME7:KAO3:HFB7:RCTP:4P45:FWLV:TI46:YLYQ:3INW:7MLD:LZ2Y:BJK3
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: codeaholics
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.)

root@server:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 17.04
Release:	17.04
Codename:	zesty
root@server:~# uname -a
Linux server 4.10.0-26-generic #30-Ubuntu SMP Tue Jun 27 09:30:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[codeaholics]

I've also tried with --security-opt seccomp=unconfined --security-opt apparmor=unconfined and that doesn't change the behaviour.

--privileged causes the device not to appear in the container at all!

[thaJeztah]

Sounds related to moby/moby#11462 (which explains a bit what happens when you start a container)

[plouj]

I can still reproduce this in Docker version 18.05.0-ce, build f150324:

plouj@host:~$ socat -ddd PTY,link=/tmp/remote-serial,rawer,wait-slave,b19200,mode=666 - &
plouj@host:~$ docker run -it --rm --device=/tmp/remote-serial:/dev/ttyUSB0:rwm ubuntu:17.10 /bin/bash
root@5e18766143c9:/# apt update && apt install minicom && minicom --device /dev/ttyUSB0
[...]
minicom: cannot open /dev/ttyUSB0: Input/output error

- stracing minicom in the container (via its parent bash process) from the outside host reveals:

[pid 13507] openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 EIO (Input/output error)

[kungfoolfighting]

@codeaholics I am trying to do the exact same thing, did you ever get it to work? If not this way, what was your workaround?

[codeaholics]

No, I didn’t. The software inside the container is open source, so I patched it to work with either serial or TCP and had it reach out directly to the `socat` on the far end without needing one on the local end.

…

On 28 May 2018, at 14:57, kungfoolfighting ***@***.***> wrote: @codeaholics I am trying to do the exact same thing, did you ever get it to work? If not this way, what was your workaround? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[coolacid]

For those that come across this I may have found a work around, one can simply use a volume mount to bindmount the FD into the container.

socat -d -d pty,raw,echo=0,link=/dev/ttyV1 udp4-listen:5000,reuseaddr

docker run -ti --volume=/dev/ttyV1:/dev/ttyV1 ubuntu:17.04 /bin/bash
root@d354ff3eb411:/# ls /dev/ -l
total 0
crw--w---- 1 root tty  136, 0 Jan 23 04:23 console
lrwxrwxrwx 1 root root     11 Jan 23 04:23 core -> /proc/kcore
lrwxrwxrwx 1 root root     13 Jan 23 04:23 fd -> /proc/self/fd
crw-rw-rw- 1 root root   1, 7 Jan 23 04:23 full
drwxrwxrwt 2 root root     40 Jan 23 04:23 mqueue
crw-rw-rw- 1 root root   1, 3 Jan 23 04:23 null
lrwxrwxrwx 1 root root      8 Jan 23 04:23 ptmx -> pts/ptmx
drwxr-xr-x 2 root root      0 Jan 23 04:23 pts
crw-rw-rw- 1 root root   1, 8 Jan 23 04:23 random
drwxrwxrwt 2 root root     40 Jan 23 04:23 shm
lrwxrwxrwx 1 root root     15 Jan 23 04:23 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root     15 Jan 23 04:23 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root     15 Jan 23 04:23 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root   5, 0 Jan 23 04:23 tty
crw--w---- 1 root tty  136, 9 Jan 23 04:22 ttyV1
crw-rw-rw- 1 root root   1, 9 Jan 23 04:23 urandom
crw-rw-rw- 1 root root   1, 5 Jan 23 04:23 zero
root@d354ff3eb411:/# cat /dev/ttyV1
Hello all

echo "Hello all" | nc -u localhost 5000

Keep in mind, if the pty goes away and is re-created, the container will not know any better and EIO any access to it

[Teawolf-beep]

Still not working in 19.03.8-ce build afacb8b7f0...however the workaround to use the pts device via the volume flag as mentioned by coolacid seems to work for now.

[kamiccolo]

Still an issue as of 24.0.5, build ced0996600

Even explicitly adding to the cgroup:

$ stat -c "%Hr %Lr" /dev/pts/4
136 4

docker run --rm --device-cgroup-rule='c 136:* rmw' --device=/dev/pts/5:/dev/my_fancy_device  -i -t my_fancy_container /bin/bash

cat /dev/my_fancy_device
cat /dev/my_fancy_device: Input/output error