Does not track devices created after container startup

[DavidMikeSimon]

I'm using DMM to grant access for my print server to a USB printer, by mounting /dev/bus/usb from host to container.

Annoyingly, the printer has a habit of disconnecting from one position on the USB bus and then randomly reconnecting to another, e.g. it moves from /dev/bus/usb/003/005 to /dev/bus/usb/003/008.

The print server software itself can handle this. But DMM does not notice the new device appearing. The only workaround I've found is to manually restart the print server's container, which triggers DMM to re-scan everything under /dev/bus/usb.

[allfro]

You can add some udev rules to create a constant symlink:

ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="printer”

You can check for the variables of your device by running:

udevadm info -a -p $(udevadm info -q path -n /dev/bus/usb/003/005)

Then you should see your printer under /dev/printer all the time.

[DavidMikeSimon]

@allfro Oh, thank you, that's a good idea! I will give it a shot!

[DavidMikeSimon]

@allfro Unfortunately, that didn't work. I was able to set up the alias and mount it into the container. However, it turns out that CUPS cannot just be given an arbitrary path to a printer device. It uses libusb to scan for the USB printer, and always tries to reach it on /dev/bus/usb/N/M based on the bus and device ids it gets back from the scan.

[jvrobert]

Related, is there a way to have it look at existing running containers on startup? Depending on the order DMM starts relative to e.g. my Jellyfin or Frigate containers they may not have access to the GPU. I can fix with restart of container, but it's kind of a nuisance when this happens when the machine reboots and DMM starts later.

I could run DMM as a service, I guess, but wondering if this is an easy fix (I may learn some Go, I guess) because it works perfectly as is as a container otherwise.