Device USB mapping going wrong, container sees unmapped devices, bug? leak?

~# docker version
Client:
 Version:           18.06.3-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        d7080c1
 Built:             Wed Feb 20 02:42:54 2019
 OS/Arch:           linux/arm
 Experimental:      false

Server:
 Engine:
  Version:          18.06.3-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       d7080c1
  Built:            Wed Feb 20 02:38:25 2019
  OS/Arch:          linux/arm
  Experimental:     false

I have two DVB-T devices for airplane tracking, each supposed to be in a different Docker container.

Instead, something goes wrong.

docker run -d --name="drpi-fr24-piaware-d1090mP" --net=MainNet --ip=172.12.0.4 -p 8081:8080 -p 8755:8754 \
--device=/dev/bus/usb/001/006 \
-v /root/piaware.conf:/etc/piaware.conf \
-v /root/config.js:/usr/lib/fr24/public_html/config.js \
-v /root/fr24feed2.ini:/etc/fr24feed.ini \
dmorehouse/raspberrypi-flightradar-flightaware-feed

docker run -d --name="drpi-fr24-piaware-d1090mA" --net=MainNet --ip=172.12.0.5 -p 8080:8080 -p 8754:8754 \
--device=/dev/bus/usb/001/008 \
-v /root/piaware.conf:/etc/piaware.conf \
-v /root/config.js:/usr/lib/fr24/public_html/config.js \
-v /root/fr24feed.ini:/etc/fr24feed.ini \
dmorehouse/raspberrypi-flightradar-flightaware-feed

The second one says it cannot access the device:

Mon Jun 24 18:32:38 2019 UTC  dump1090-mutability v1.15-dev-327-gb155fdb starting up.
Jun 24 20:32:38: Using sample converter: UC8, integer/table path
Jun 24 20:32:38: libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Operation not permitted
Jun 24 20:32:38: Found 2 device(s):
Jun 24 20:32:38: libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Operation not permitted
Jun 24 20:32:38: 0: unable to read device details
Jun 24 20:32:38: libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Operation not permitted
Jun 24 20:32:38: 1: unable to read device details
Jun 24 20:32:38: libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Operation not permitted
Jun 24 20:32:38: usb_open error -4
Jun 24 20:32:38: Error opening the RTLSDR device: No such file or directory

Inside the container errors:

Mon Jun 24 18:51:47 2019 UTC  dump1090-mutability v1.15-dev-327-gb155fdb starting up.
Using sample converter: UC8, integer/table path
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Operation not permitted
Found 2 device(s):
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Operation not permitted
0: unable to read device details
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Operation not permitted
1: unable to read device details
libudev: udev_has_devtmpfs: name_to_handle_at on /dev: Operation not permitted
usb_open error -4
2019-06-24 18:51:47 | [reader][i]Connection terminated
2019-06-24 18:51:47 | [main][i]Terminating child process 56 with SIGTERM

How is that container even able to see that there are multiple USB devices when only one of them is being mapped? :confused:

On host:

~# lsusb
Bus 001 Device 006: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

it does exist. And the right mapped /dev/bus/usb/001/???s can be found in the containers.

Here log from the container that runs successfully:

Mon Jun 24 19:22:05 2019 UTC  dump1090-mutability v1.15-dev-327-gb155fdb starting up.
Using sample converter: UC8, integer/table path
Found 2 device(s):
0: Realtek, RTL2832U, SN: 00001000 (currently selected)
1: Realtek, RTL2838UHIDIR, SN: 00000001 
Found Rafael Micro R820T tuner
Max available gain is: 49.60 dB
Setting gain to: 49.60 dB
Gain reported by device: 49.60 dB

So indeed, while only one device is being mapped, the container can see both.

This should only happen with --privileged , which I am explicitly not using.

Bug/leak?

Or is my mapping option non-existent, as in; you can only map the whole USB-bus and not a single /dev/bus/usb/???/??? device?

Kicking topic before opening bug report.