But when we add the --privileged flag to this, it’s causing issues with our other devices. Note: /dev/rplidar and /dev/myserial are custom USB rules / symlinks that are needed inside docker. It seems like the privileged flag is overwriting these symlinks (when I run ls \dev | grep lidar without privileged flag, I see the device, but when I run it with the flag, I don’t see the device) So just wondering if there’s a way to manually pass the Zed camera device into the docker container.
I checked the link you suggested - our Docker container (one of dustynv’s Zed containers) runs as root user, so I don’t think that solution applies to our case.
Is there no way to run the Zed camera in Docker without privileged flag? It seems like it’s a matter of identifying the right devices to pass into Docker using “-- device”.
I’m not sure the solution from the other thread will work. The USB controllers are not very reliable depending on the computer you use. There are mecanisms in the SDK that try to recover the camera when it goes down and, for that, passing the device is not enough (since the device can change).
@alassagne yes I understand that and I’ve tested it works, but since it creates a conflict as described in my post above, I was looking for any other way apart from that method?
Did you try the solution from the thread you mentioned ? I mean, setup the udev rules on the host. That should work… until your USB controller breaks, and the SDK will not be able to recover. You’ll have to implement the recovery yourself.
Hi @alassagne, actually we installed the SDK both on the host (Jetson NX) and inside the Docker container, so the udev rules are indeed there.
I found a temporary workaround although I’m not sure how stable this is. I still start the Docker container in privileged mode. But then add the custom udev rules inside the container that map ttyUSB* to /dev/rplidar & /dev/myserial and then reload the rules. These custom rules were on the host, but seem to get erased when using privileged mode (as described in the post above). So this seems to work for now, hopefully it doesn’t cause any conflicts/clashes with Zed. What do you think?
Additionally, are there any udev rules to map the Zed camera to a symlink such as /dev/myzed? This would be very helpful too. If not, maybe I should mount the whole /dev volume into the container?
What I do usually is indeed mount the whole /dev volume into the container. if you are using ZED X, you should also mount /tmp/argus_socket and /var/nvidia/nvcam/settings/