The phone is waiting at its bootloader screen, the cable is connected, and Fastboot answers with “no permissions.” It is tempting to put sudo in front of every command and keep moving. Please pause there: flashing as root hides the access-control problem and makes a dangerous command more powerful.

There are really three different failures that look similar from the terminal: Linux never enumerated the USB device, the phone is not exposing a Fastboot interface, or udev created the device node without access for your user. We will identify which one you have before changing a rule.

Draw the fault line with two observations

Terminalbash
lsusb
fastboot devices -l

Read these results as a diagnosis, not a ritual

  • If the bootloader does not appear in lsusb, a udev permission rule cannot help: try a known data-capable cable, a direct USB port, and the device’s documented Fastboot mode.

  • If lsusb shows the bootloader but Fastboot reports no permission, Linux detected it and access to its /dev/bus/usb node is the likely problem.

  • If fastboot devices -l is simply empty, confirm the screen actually says Fastboot or bootloader. ADB recovery, download mode, and vendor flashing modes are different USB protocols.

  • The four hexadecimal digits before the colon in lsusb are the vendor ID; the four after it are the product ID. Bootloader IDs can differ from Android’s normal running-mode IDs.

  • No output here is claimed as a universal expected result; model, bootloader, cable, host, and virtualization all affect enumeration.

Make sure you are debugging the Fastboot you think you are

Terminalbash
command -v fastboot
fastboot --version

Why the executable path matters

  • command -v exposes an older binary earlier in PATH, a packaged wrapper, or a different SDK installation.

  • Google distributes Fastboot in Android SDK Platform Tools and recommends using the latest release; update from the official package when an old binary behaves unexpectedly.

  • Do not mix sudo fastboot and normal-user Fastboot while testing. Root may resolve a different PATH, making the comparison misleading.

On Ubuntu, try the maintained rules before inventing one

Terminalbash
sudo apt update
sudo apt install android-sdk-platform-tools-common
id

Risk level: caution. Review the command before running it.

What changes—and what does not

  • Android’s hardware-device documentation points Ubuntu users to android-sdk-platform-tools-common for community-maintained udev rules.

  • apt update refreshes package metadata; apt install changes system packages and therefore requires administrator review.

  • The same documentation requires membership in plugdev for its Ubuntu workflow. id lets you verify the current session rather than assuming the account database and session agree.

  • If an administrator adds you to plugdev, the change normally takes effect after logging out and back in. Re-running Fastboot in the old session does not prove the group change failed.

  • These Android instructions discuss hardware-device access broadly and are ADB-oriented; always confirm the installed rules actually match the vendor ID exposed in Fastboot mode.

If no maintained rule matches, create the narrowest local rule

Replace 18d1 below with the lowercase vendor ID shown by lsusb while this exact device is in Fastboot mode. Keep the product match only when you deliberately want to authorize one bootloader interface; omitting it applies the rule to every USB product from that vendor.

51-android-fastboot.rulestext
# Replace 18d1 with the Fastboot-mode vendor ID from lsusb
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0660", GROUP="plugdev", TAG+="uaccess"

A local Linux udev rule using group access and the active-seat uaccess tag.

The boundaries built into this rule

  • SUBSYSTEM=="usb" prevents the rule from matching unrelated device classes.

  • ATTR{idVendor} must come from the bootloader’s real USB identity; copying Google’s example ID for another vendor silently fails or grants access to the wrong family.

  • MODE="0660" permits owner and group access without making the node writable by every local user. Old advice using 0666 is unnecessarily broad on shared systems.

  • GROUP="plugdev" supports the Ubuntu group workflow; TAG+="uaccess" lets systemd-logind grant an active local seat access on distributions configured for it. Remote, headless, and non-systemd systems vary.

Terminalbash
sudo install -m 0644 51-android-fastboot.rules /etc/udev/rules.d/51-android-fastboot.rules
sudo udevadm control --reload-rules

Risk level: caution. Review the command before running it.

Why reloading is only half the job

  • install -m 0644 copies the local file into the system rules directory with predictable permissions; inspect the file before running it.

  • udevadm control --reload-rules affects future events. It does not retroactively recreate the USB device node already present.

  • Unplug and reconnect the USB cable, or leave and re-enter Fastboot mode, so udev receives a fresh add event. Avoid restarting the entire udev service as a generic first step.

Verify the node, the rule, and Fastboot as yourself

Terminalbash
lsusb
ls -l /dev/bus/usb/BBB/DDD
udevadm info --query=property --name=/dev/bus/usb/BBB/DDD
fastboot devices -l

Evidence that closes the loop

  • BBB and DDD are zero-padded bus and device numbers and can change after every reconnect; never preserve an old path in a script.

  • ls -l shows the device node’s mode and group. udevadm info shows properties and tags associated with that node.

  • Run the final Fastboot command without sudo. A serial plus fastboot confirms discovery and access; it does not authorize flashing or prove that the bootloader is unlocked.

  • If the rule appears not to match, inspect spelling, quoting, the actual Fastboot vendor ID, rule-file suffix, and the journal rather than repeatedly broadening permissions.

When udev is innocent

  • Cable or port: a charge-only or marginal cable can power the phone while data enumeration fails. Avoid an unpowered hub during diagnosis.

  • Virtual machine: attach the bootloader USB identity to the guest again after rebooting the phone; the product ID may change when Android leaves ADB mode.

  • WSL: Linux udev rules inside WSL do not automatically control Windows USB ownership. Use Microsoft’s current USB attachment workflow or run the Windows Platform Tools instead.

  • Container or sandbox: the host must pass the USB node into the environment, and confinement may still deny it even when host udev permissions are correct.

  • Competing process: close Android Studio, vendor flash tools, and stale Fastboot processes if one of them has claimed the interface.

Keep a rollback beside the fix

Terminalbash
sudo mv /etc/udev/rules.d/51-android-fastboot.rules /etc/udev/rules.d/51-android-fastboot.rules.disabled
sudo udevadm control --reload-rules

Risk level: caution. Review the command before running it.

A calm way back

  • mv makes this targeted change reversible and avoids deleting unrelated Android rules.

  • Reconnect the device after reloading so the replacement policy is applied to a new event.

  • If a distribution package installed the relevant rule, manage that package instead of renaming files it owns.

Continue with the right Android tool

Primary references