Permission denied

Access to the probe was refused — usually because another debugger already has it open.

PERMISSION_DENIED

Symptoms

  • The probe is listed in MCUHex, but connecting fails immediately with "Access denied (insufficient permissions)" or LIBUSB_ERROR_ACCESS.
  • It started right after using STM32CubeIDE, STM32CubeProgrammer or OpenOCD — and works again once that program is closed.
  • On Linux the probe appears in lsusb but only opens when the SDK is run with sudo.
  • On Windows the probe shows a warning icon in Device Manager, or only works in one specific tool.

Likely causes

  • Another debugger already claimed the USB interface. On macOS and Windows the operating system reports that exclusive claim as an access error rather than a busy one, so contention and a real permission problem arrive as the same code.
  • Linux: missing udev rules — USB devices are owned by root by default, so your user account cannot open the probe.
  • Windows: no permission is involved — the probe is unreachable until its interface is bound to WinUSB.
  • macOS: no permission is involved either — the system has no per-app USB setting, so an access error here always means something else holds the probe.
  • The SDK runs as a different user than the one the udev rule grants access to.

How to fix it

  1. Close whatever else is talking to the probe

    STM32CubeIDE (including a debug session left running in the background), STM32CubeProgrammer, OpenOCD, a gdbserver, or a second copy of the MCUHex tray app. Quit it fully — an IDE that is merely idle can still hold the interface — then retry.

  2. Confirm the probe is actually free

    If closing the other tool did not help, unplug and replug the USB cable. That releases any claim left behind by a program that exited badly. On macOS and Windows this resolves most access errors; if it does not, the cause is a real permission or driver problem and the steps below apply.

  3. Linux: install the probe udev rules

    Install ST’s rules, or pyOCD’s ruleset covering ST-Link, J-Link and CMSIS-DAP, then reload udev. A minimal ST-Link V2/V3 rule is shown below.

    sudo cp 49-stlinkv2.rules 49-stlinkv3.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger

# minimal rule contents (V2 / V2-1 / V3):
SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="0666", TAG+="uaccess"
SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="374b", MODE="0666", TAG+="uaccess"
SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="374e", MODE="0666", TAG+="uaccess"

  4. Linux: replug the probe

    udev rules apply on device insertion — unplug and replug the USB cable after reloading rules. Do not keep running the SDK with sudo as a workaround.

  5. Windows: bind the probe to WinUSB

    Windows has no USB permission to grant — the probe is reachable only when its interface is bound to WinUSB. If STM32CubeIDE or STM32CubeProgrammer is installed, its driver already does that. Otherwise open Zadig and select the probe: “ST-Link Debug (Interface 0)” on a Nucleo or Discovery board, “STM32 STLink” on a stand-alone dongle, USB ID 0483 either way (Options → List All Devices if it is not shown). Pick WinUSB as the target driver, install, then replug. This is a driver installation, so it needs an administrator account.

  6. macOS: there is nothing to allow

    macOS has no per-app USB permission setting. The one control that exists, “Allow accessories to connect”, blocks the device from appearing at all — so if the probe is listed in MCUHex, the system has already granted access and the cause is another program holding it.

  7. Retry in MCUHex

    Refresh the device list. The probe should now open without elevated privileges.

Related errors