USB3 Vision camera not detected on Linux: fix udev permissions

A USB3 Vision camera with its power LED lit, present in lsusb and absent from your SDK's camera list, is almost always a permissions fault rather than a broken camera. The kernel sees the device; your login session does not. This guide is for engineers integrating USB3 Vision area-scan cameras on Linux workstations. You will pin the fault with two launches of your SDK, restore non-root access with the vendor's documented udev setup or access group, prove the fix survives a reboot, and decide when the cable, the link speed or the interface choice is the real problem.

Why does a USB3 Vision camera power up but never appear in your SDK on Linux?

The camera, cable and port are usually healthy. The udev rules that grant a non-root user access to the device were never installed or were invalidated, so the kernel sees the camera but your login session has no permission to open its device node.

Linux hands out USB devices as nodes under /dev/bus/usb/. udev creates each node owned by root, and an ordinary user process that tries to open it gets an access error. USB3 Vision SDKs enumerate through a user-space USB library such as libusb, which must open the node to read the camera's descriptors. A permission gap therefore looks exactly like a missing camera: no listing, and no error message pointing at permissions.

The gap opens when the SDK setup ran without its udev step. Installers ask, near the end, whether to configure device rules for non-root use; a skipped prompt or an aborted install leaves every camera node root-only. The udev rules guide for USB cameras explains the rule mechanism itself; this page is the decision path around it. If the camera is invisible even under sudo, work the SDK device isolation checklist instead.

How do you prove the fault is permissions and not a dead camera?

Run your SDK's enumeration tool twice, once with sudo and once as your normal user. A camera that appears under sudo but not as your user has a working USB link and a broken permission layer, and no cable swap will change that.

Launch your SDK's viewer from a terminal with sudo in front of the usual command, then again without it. If sudo lists the camera and your user does not, the camera, cable, port and driver are all proven good, and only the permission layer needs work. If sudo also lists nothing, the fault sits in the bus or the link, and the speed checks further down are the next stop.

Two more commands pin the node itself:

lsusb                        # the camera appears in the list
ls -l /dev/bus/usb/003/002   # Bus 003 Device 002 maps to this node

The node prints root:root with no write bit for other users, which is the whole fault in one line.

A camera that shows in lsusb but not in the SDK has its own lsusb-but-not-SDK walkthrough with overlapping causes. Run it if the permission fix below does not resolve the listing.

Which udev rules give the camera to non-root users?

The file your SDK's installer offers to write into /etc/udev/rules.d/ when you accept its setup prompt. It matches the camera's USB identity and hands the device to your desktop user with a mode, a group or a uaccess tag.

Three mechanisms do the granting. A mode opens the node to every local process. A group hands it to the SDK's own access group. A uaccess tag gives access to whichever user is logged in at the desktop. Vendor installers write one of the three into /etc/udev/rules.d/, and the clean route is to let them: run the SDK installer again, accept the udev prompt, and let it match the rule to the camera for you. Hand-written rules belong in /etc/udev/rules.d/ as well, never in the system directories the package manager owns.

For the same repair walked through end to end on a desktop Ubuntu 22.04 system, the Ubuntu camera-permission walkthrough follows the installer prompts step by step.

How do you add your user to the SDK's access group?

Add the group the SDK created to your user with usermod -aG. Use the exact group name printed in the SDK's Linux install notes, then start a fresh login so the kernel hands out the new membership.

Find the group name in the installer output or the SDK's Linux installation notes; the route only works with the exact name. In the commands below, mvaccess stands in for that group name and ops for the user you are fixing:

groups                         # what your user belongs to today
sudo usermod -aG mvaccess ops  # mvaccess = the SDK's group, ops = your user

The -a flag appends the group. usermod with -G alone would replace every other supplementary group the account holds, which on a shared build host can cut an operator out of groups the station depends on. A fresh groups should then print the new name — but only from a new login, which is the next section's subject.

Why does nothing change until you log out and replug the camera?

Group membership is read once at login, and udev ownership is applied only when the device appears on the bus. A rule change without a replug — or a usermod without a logout — leaves the system exactly as it was.

Apply both sides:

sudo udevadm control --reload-rules   # only needed for hand-written rules
sudo udevadm trigger                  # or simply unplug and replug the camera

Then log out and back in, or reboot once and clear both caches at the same time. newgrp starts a shell that already carries the new group if you want a quick test without a full logout. After the replug, ls -l /dev/bus/usb/003/002 should show the SDK's group owning the node instead of root:root.

The replug matters more than it seems: udev rebuilds the node every time the device appears, so a permission changed directly on the old node does not survive it.

Why does a camera that lists on the bus still fail at USB 2.0 speed?

A cable, extension or front-panel port that cannot carry SuperSpeed drops the link to 480 Mb/s. That is about a sixth of the bandwidth a 12 MP camera at 30 fps needs, so the stream stalls even though the device still lists.

lsusb -t prints the negotiated speed per port: 5000M is a healthy SuperSpeed link, 480M is the fallback. dmesg says the same thing in words:

sudo dmesg | grep -i superspeed
# new SuperSpeed USB device ... = linked at 5 Gb/s
# new high-speed USB device ... = fell back to 480 Mb/s

The usual culprits, in order: a cable not rated for SuperSpeed, a passive extension or an unpowered hub, a front-panel header wired for USB 2.0, and a USB2-only port behind a blue connector shell. If lsusb itself comes up empty, start from the cable-swap checklist instead. Otherwise swap to a short, rated cable straight into a rear motherboard port: a 3 m high-flex USB3.0 camera cable is the known-good swap that ends the argument.

Bandwidth explains why a fallback fails hard instead of degrading. The LS-CMR-0166 prints 4000 × 3000 at 30 fps over USB3. Work the stream for a 4000 × 3000 sensor in 8-bit mono, one byte per pixel:

USB 3.0 carries the full stream with room to spare; USB 2.0 carries a sixth of it, so the camera drops frames, times out or is refused outright. A fallback never looks like a slower camera — it looks like no camera.

Once the permission layer is correct, any in-production USB3 Vision camera enumerates for your user without further ceremony. For a new bench build, the LS-CMR-0166 gives 12 MP at 30 fps over USB3 from a 1/1.7" rolling-shutter sensor. Embedded ARM boards add controller quirks of their own, and the USB3 camera fallback walkthrough for embedded boards covers the board-side checks.

How do you verify the fix and prove it survives a reboot?

Check three things in order: the device node now carries your group, the groups command lists that group for your user, and the SDK's enumeration finds the camera as your normal user — then reboot once and repeat, because only a reboot proves the rules file persists.

1. groups prints the SDK's access group among your memberships.
2. ls -l /dev/bus/usb/003/002 shows that group owning the node after a replug.
3. The SDK's viewer, launched normally, lists the camera, and grabbing one frame proves open access rather than a listing-only hit.
4. Reboot, log back in, replug, and run the three checks again; rules under /etc/udev/rules.d/ and group membership both persist, and the reboot is what demonstrates it.

For V4L2-style /dev/video nodes from other camera families the same ownership logic applies; the video and media node permission checks cover that variant.

When should you stop debugging USB and specify a GigE camera instead?

Move to GigE when the run is longer than a camera-grade USB cable, when two or more cameras share one host controller, or when you cannot install udev rules on a locked-down host. One Cat 6 run reaches 100 m and removes the whole USB permission stack.

Length decides first: camera-grade USB3.0 cables run to a few metres, while GigE over Cat 6 is specified to 100 m. Bandwidth decides second: two 12 MP USB3 cameras want roughly 720 MB/s combined, which is beyond what one USB 3.0 host controller sustains, and the fight surfaces as stalls that look like software bugs. Control decides third: on a customer-owned or locked-down host where installing rules is off the table, an Ethernet interface needs no device-node permissions at all.

For a bench moving that way, the MV-CU020-90GC is a 2.5 MP GigE camera with a 1/1.7" global-shutter sensor:

GigE trades the USB stack for an Ethernet one, with its own enumeration chain of IP addresses, subnets and MTU settings; the GigE enumeration guide is the matching article for that interface. When you are specifying rather than rescuing, the area scan cameras page filters by interface and resolution, the camera finder narrows by sensor and shutter, and the configurator walks the chain from camera to cable. If the choice is between repairing a USB host and changing interface, the contact page reaches the applications team.