Reset a Stuck USB Device Safely with usbreset

A USB device locks up and unplugging it is not always convenient: usbreset sends it a port reset instead, no cable pull required. It can make an unresponsive device recover, but it briefly disrupts that device and can affect anything using it, so check the result before you trust it.

Allow about ten minutes for a single device. You need the usbutils package and a shell. The examples use usbreset 017 from package version 1:017-3build1, installed here as /usr/bin/usbreset. Device names, numbers and permissions vary by host.

1. Confirm the installed command

Start with read-only checks. This does not reset anything and normally needs no elevated privileges:

$ command -v usbreset
/usr/bin/usbreset
$ dpkg-query -W -f='${Package} ${Version}\n' usbutils
usbutils 1:017-3build1
$ usbreset
Usage:
  usbreset PPPP:VVVV - reset by product and vendor id
  usbreset BBB/DDD   - reset by bus and device number
  usbreset "Product" - reset by product name

Devices:

With no argument, this installed build prints usage and lists the devices it can inspect, then returns status 1. An empty device list means there is no matchable USB device in the view available to this process; it is not a reason to guess an identifier.

Checkpoint: If command -v finds nothing, install or enable usbutils through your normal package-management process first. Do not compile a different copy just to make an example fit this guide.

2. Record the target before touching it

Use the no-argument output to choose a target by its bus and device number, vendor and product IDs, or product name. The installed manpage documents these forms:

There is a naming inconsistency worth calling out. The local manpage describes the colon form as product then vendor, while its example labels 1234:5678 as vendor 1234 and product 5678. The installed program's own usage text also says PPPP:VVVV. Do not resolve that ambiguity by trial-and-error on real hardware; prefer the bus/device form from the same listing, or inspect the installed source and package documentation for the exact build.

The upstream usbutils source currently parses the colon form as vendor ID followed by product ID, and the source also contains a serial-number form. Those details are not documented by this machine's usbreset(1) page, so this guide does not rely on them. Treat the locally installed manpage and usage output as the contract for a reproducible run.

3. Warn the user of the interruption

Safety warning: A USB reset is a state-changing, service-disrupting action. It sends a reset request to the selected device through /dev/bus/usb/; it is not merely a status query. Stop a file copy, unmount removable storage, and pause any application talking to the device. A hub reset can affect devices downstream of that hub.

Check the target again immediately before the reset. USB bus and device numbers can change after a reconnect, so an old BBB/DDD value may name a different device later. If the device is business-critical, use a maintenance window and keep a physical recovery route available.

4. Send one reset

Replace BBB/DDD with the exact bus/device pair printed on your host. This is the operation that changes device state:

$ usbreset BBB/DDD
Resetting Product name ... ok

The successful output contains the device product name and ends with ok. The command returns status 0 when it finds the device and the reset ioctl succeeds. It does not tell you that an application has recovered, so continue to the verification step.

Access to the USB device node may require elevated privileges on your system. Try the ordinary command first. If it reports that it cannot open the device, check the node and permissions:

$ ls -l /dev/bus/usb/BBB/DDD
$ usbreset BBB/DDD
Resetting Product name ... can't open [Permission denied]

Only if your local policy permits it, retry the same exact target with sudo:

$ sudo usbreset BBB/DDD
Resetting Product name ... ok

Do not use sudo to compensate for an uncertain device selection. It raises the stakes of a mistake; it does not make an ambiguous identifier safe.

5. Verify the device and application

There is no undo command for a USB reset. Recovery means letting the device re-enumerate and then restarting only the affected user-space operation if necessary. Wait briefly, then inspect the device list again:

$ usbreset
Usage:
  usbreset PPPP:VVVV - reset by product and vendor id
  usbreset BBB/DDD   - reset by bus and device number
  usbreset "Product" - reset by product name

Devices:
...the device appears again...

Use lsusb when it is installed to confirm that the expected vendor, product and bus/device identity has returned. Then test the application that was failing. A successful reset only proves the kernel accepted the request: it does not guarantee a storage filesystem was cleanly unmounted, that a camera stream resumed, or that a serial client reconnected.

If the device disappears, do not repeatedly reset it. Check kernel messages with your system's normal logging tool, reseat the cable only when safe, and follow the device or service recovery procedure. For removable storage, check mounts before unplugging it; a reset is not a substitute for a clean unmount.

6. Handle the common failures

No such device found means the supplied selector did not match a device. Re-run usbreset without arguments and copy a current bus/device pair. Do not assume the number printed by an old log is still valid.

If several devices share a product name or IDs, the name is a poor selector: use the bus/device form shown in the current listing. If the device reconnects between listing and reset, collect a fresh listing rather than escalating privileges.

If the reset prints failed, the device was found but the kernel rejected the reset request. Preserve the exact error text, check kernel logs, and investigate driver or hardware state. Running the same command in a loop can turn a recoverable problem into repeated service disruption.

Done means