for-linux
for-linux copied to clipboard
Cannot access mounted pts device inside container
- [x] This is a bug report
- [ ] This is a feature request
- [x] 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
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!
Sounds related to https://github.com/moby/moby/issues/11462 (which explains a bit what happens when you start a container)
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)
@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?
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 [email protected] 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.
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
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.
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