Bind mounting a dynamic /dev resource

Technical Support
, , ,
1

What is the preferred way to bind mount a dynamic resource? I have an application which relies on a USB peripheral, /dev/ttyUSB0. Right now, I have /dev/ttyUSB0 configured as a bind-mounted volume in my docker-compose.yml file. This works fine, as long as the peripheral is connected (and, indeed, enumerated as ttyUSB0, which isn’t necessarily always going to be true). Can I have the application instead do the bind mount dynamically? Is this possible within the application container?

It seems like bind-mounting the entire /dev directory does not work–this would be my preferred approach as I’d like to be able to scan the whole directory for hardware changes and to confirm the name of the resource.

2

Greetings @mosaic-engineering,

If I understand you correctly. With bind-mounting dynamic directories you’ll want to specify a bind-mount with shared propagation: Use bind mounts | Docker Documentation

This should propagate any changes in the bind-mount allowing these dynamic directories.

I tried this before with USB/SD devices that were removed/attached while the container was running and it worked fine for that. I never tried with a dynamic /dev before but it seems to be a similar enough situation.

Could you give this a try and let me know how it works for you?

Best Regards,
Jeremias

3

Hi Jeremias,

Perhaps I misspoke. I’m not using bind-mounts (I don’t think). I’m listing the USB device under the devices section of my docker-compose.yml, as shown below. This works fine, as long as /dev/ttyUSB0 is connected at boot. But it fails if this device is not connected. How can I ensure it doesn’t fail to load my container at boot if /dev/ttyUSB0 is unavailable?

# docker-compose.yml
services:
  lari2-firmware-1:
    depends_on:
    - weston
    devices:
    - /dev/gpiochip0
    - /dev/gpiochip1
    - /dev/gpiochip2
    - /dev/gpiochip3
    - /dev/gpiochip4
    - /dev/gpiochip5
    - /dev/spidev0.0
    - /dev/spidev1.0
    - /dev/apalis-uart1
    - /dev/apalis-uart2
    - /dev/apalis-uart3
    - /dev/apalis-uart4
    - /dev/ttyUSB0
    image: fbmyers/lari2-firmware-1
    ports:
    - 6502/tcp
    volumes:
    - /tmp:/tmp:rw
    - /dev/dri:/dev/dri:rw
    - /sys:/sys:rw
    - /var/lari:/var/lari:rw
    - /sys/class/pwm/pwmchip0:/sys/class/pwm/pwmchip0:rw
    - /sys/class/pwm/pwmchip2:/sys/class/pwm/pwmchip2:rw
    - /sys/class/pwm/pwmchip3:/sys/class/pwm/pwmchip3:rw
4

Well what I was thinking is adding a volume for all of /dev. Since /dev/ttyUSB0 is not always available on container start for you we need to go one level higher and look at all of /dev. As far as I know, I don’t believe there’s a way to add a device for a path that doesn’t exist yet.

So if you bind-mount all of /dev as a volume into the container. This will allow your container start even if /dev/ttyUSB0 isn’t available yet. Then once it is available you can then reference it in your container through the /dev bind-mount. If that all makes sense.

Best Regards,
Jeremias

5

I wasn’t able to do this via bind-mounting /dev, but running my container in privileged mode worked. I removed all entries under “devices” in docker-compose and I added “privileged: true”. As I understand, this basically makes the entire /dev directory available to your container.

6

As I understand, this basically makes the entire /dev directory available to your container.

Well the privileged flag gives that container “almost” root privileges. You still need to bind mount things into your container so that it can “see” them. It just has increased privileges now. There are security implications of course with doing this, therefore it’s not usually recommended.

Ok so back up what was happening before then? You bind-mounted all of /dev then what? When you connect your USB device was /dev/ttyUSB0 not made available via the /dev bind-mount? Did you configure bind-mount propagation?

Best Regards,
Jeremias