Export a USB Device Safely with usbipd

usbipd hands a USB device to any client that can reach its port, no password asked. The installed manual says it provides no authentication or authorisation at all. This walkthrough turns one locally attached device into a USB/IP export, starts the server on TCP port 3240, and then undoes the export so the device can be used locally again.

Allow about 15 minutes, plus time to identify the correct device. You need root access, the usbip utilities, a USB device that is safe to make available to another host, and a firewall or private network boundary you trust. Do not export keyboards, storage holding private data, or a device a running service needs, unless you have a recovery plan.

The examples below follow the usbipd manual installed with Ubuntu package linux-tools-common version 6.8.0-142.142. The local /usr/bin/usbipd is a kernel-version dispatcher. If the matching kernel tools are absent, it prints a warning and exits instead of starting the daemon.

1. Check the local tool and the network boundary

First confirm the package and the command path. These checks are read-only and need no elevated privileges:

$ command -v usbipd
/usr/bin/usbipd
$ dpkg-query -W -f='${Package} ${Version}\n' linux-tools-common
linux-tools-common 6.8.0-142.142

usbipd listens on TCP port 3240 by default. The manual does not describe authentication or authorisation. Before starting it, restrict that port to the client network with your host firewall, or place the server on a network where only intended clients can connect. The -4 and -6 options select IPv4 or IPv6; without either, the default is both.

Security warning: Do not expose port 3240 to an untrusted network. Starting the daemon is a security-sensitive change because it creates a network service with no built-in access control.

2. Check which USB devices are local

Run the client-side listing command as root so the device information and later driver operation use the same privilege level:

# usbip list --local

The output is host-specific. Find the exact busid for the device you intend to export, such as 1-2. Do not infer a bus ID from a label or reuse one from a previous machine. If the device is in use, stop the application or service that owns it before continuing.

Checkpoint: Write down the exact bus ID and confirm the physical device. A mistaken bus ID can make a different device exportable.

3. Load the host driver and bind one device

The manual's server example loads the USB/IP host module, then binds a device. Both operations change kernel device handling and require root:

# modprobe usbip-host
# usbip bind --busid=1-2

Replace 1-2 with the bus ID you recorded. A successful bind makes that device exportable. It is not yet reachable over the network until usbipd is running.

Warning: Binding changes which local driver controls the device. If a local program needs it, stop that program first. Keep this undo command ready:

# usbip unbind --busid=1-2

That unbind operation stops exporting the device so a local driver can use it again. If the device does not return to its normal local state, check the service that normally claims it and inspect the kernel log before repeatedly rebinding it.

4. Start usbipd in the foreground first

Run usbipd without -D for the first test. This leaves its messages attached to your terminal and avoids creating a background service before the device and firewall are ready:

# usbipd --debug

The daemon accepts USB/IP client connections on port 3240 by default. The debug process stays in the foreground, so leave this terminal open while testing from the client, and use a second terminal for client operations.

To choose a different port, supply --tcp-port:

# usbipd --debug --tcp-port 43240

Use the same port in the client's usbip commands and in the firewall rule. Do not treat a custom port as an access-control measure; it is only a different listening address.

5. Verify the export from a client

From an authorised client, list the server's exports. This is an ordinary client command, but attaching a USB device changes the client's hardware state:

# usbip list --remote=SERVER_NAME

Replace SERVER_NAME with the server's host name or address. The output should list the device bound in step 3. If the client cannot connect, check the server address, the selected port, the firewall, and whether the foreground usbipd process is still running. If the connection works but no device appears, stop and recheck the bus ID and bind operation.

To attach the exported device, load the client's virtual host controller and use the exact bus ID shown by the remote listing:

# modprobe vhci-hcd
# usbip attach --remote=SERVER_NAME --busid=1-2
# usbip port

usbip port lists imported devices and gadgets. The attached device is now controlled by the client, so do not use it locally on the server at the same time.

6. Stop the test and restore local use

Detach the device on the client before changing the server:

# usbip port
# usbip detach --port=0

Replace 0 with the port number reported by usbip port. Then return to the server terminal and stop the foreground usbipd process with Ctrl-C. Finally remove the USB/IP binding:

# usbip unbind --busid=1-2

For a daemon started with -D, use the process-management method approved for your host to stop it, then run the same unbind command. The manual documents the default PID file as /var/run/usbipd.pid when no path is supplied to --pid. A custom path can be given with --pid FILE; write it only in a directory whose ownership and permissions you have checked.

7. Use daemon mode only after the test works

Once the foreground test succeeds and the firewall rule is in place, the documented background form is:

# usbipd --daemon

Use --ipv4 or --ipv6 if the host should listen on only one address family, and --debug while diagnosing startup or connection problems. Do not combine daemon mode with a forgotten, broadly reachable firewall rule: backgrounding removes the terminal reminder but adds no security of its own.

Done means