TMKB-M1 WebHID on Linux: NotAllowedError / Failed to open the device — udev hidraw fix (Arch, Ubuntu, Fedora, etc.)

TMKB-M1-Linux-WebHID-udev.md

TMKB-M1 WebHID config site fails on Linux (NotAllowedError: Failed to open the device)

Symptom

On https://m1.tmkb.com/ (TMKB M1 mouse configuration center):

1. Click Connecting devices
2. Chrome’s HID picker appears and lists TMKB-M1
3. Select the device → Connect
4. The UI returns to the connect screen as if nothing happened

In DevTools you may see logs like devices selected / connecting..., but no successful device session. Opening the device manually throws:

NotAllowedError: Failed to open the device.

This happens even though:

• The mouse works as a normal input device
• Chrome can enumerate the HID interfaces
• The site works on Windows/macOS

Root cause

Chrome WebHID on Linux talks to the device through /dev/hidraw*.

For TMKB vendor IDs 32c2:0026 (mouse) and 32c2:0025 (receiver), those nodes are often created as:

crw------- 1 root root ... /dev/hidrawN

i.e. root-only. The browser may still show the device in the permission picker (enumeration), but device.open() fails with NotAllowedError because userspace cannot open the hidraw node.

The website also swallows some connect errors, so the failure looks like “it just didn’t detect the mouse.”

Confirm

lsusb | grep -i 32c2
# example:
# Bus 003 Device 013: ID 32c2:0026 OM6239 TMKB-M1

# Find matching hidraw nodes (names vary):
for d in /sys/class/hidraw/hidraw*; do
  v=""
  p=""
  cur=$(readlink -f "$d/device")
  for _ in $(seq 1 12); do
    if [ -f "$cur/idVendor" ]; then
      v=$(cat "$cur/idVendor")
      p=$(cat "$cur/idProduct")
      break
    fi
    cur=$(dirname "$cur")
  done
  if [ "$v" = "32c2" ]; then
    echo "$(basename "$d") vendor=$v product=$p"
    ls -l "/dev/$(basename "$d")"
  fi
done

If you see root root and mode 600 (crw-------), that’s the problem.

The vendor config interface is typically the one with HID usage page 0xFF0F / report ID 14 (not the plain mouse/keyboard interfaces).

Solution (udev)

Yes — Ubuntu, Fedora, Arch, CachyOS, openSUSE, etc. all use udev (almost always systemd-udev). The same rule works across them.

1. Ensure your user can access the input group

groups
# should include: input

If not:

sudo usermod -aG input "$USER"
# log out and back in (or reboot) so the new group applies

2. Add a udev rule

Create /etc/udev/rules.d/99-tmkb-hidraw.rules:

# TMKB-M1 mouse (wired / config interface)
KERNEL=="hidraw*", ATTRS{idVendor}=="32c2", ATTRS{idProduct}=="0026", MODE="0660", GROUP="input", TAG+="uaccess"

# TMKB-M1 receiver (2.4G dongle)
KERNEL=="hidraw*", ATTRS{idVendor}=="32c2", ATTRS{idProduct}=="0025", MODE="0660", GROUP="input", TAG+="uaccess"

3. Reload udev and replug

sudo udevadm control --reload-rules
sudo udevadm trigger

Unplug and replug the mouse's USB cable.

4. Verify permissions

# replace N with your TMKB hidraw numbers
stat -c '%n owner=%U group=%G mode=%a' /dev/hidrawN

You want something like:

/dev/hidraw10 owner=root group=input mode=660

(owner stays root; group=input is what matters.)

5. Fully restart Chrome

A tab reload is often not enough. Quit Chrome completely and reopen it, then visit https://m1.tmkb.com/ again.

Distro notes

Distro family	Uses udev?	Notes
Arch / CachyOS / EndeavourOS	Yes	Rule path above works as-is
Fedora / RHEL / CentOS	Yes	Same rule; ensure user in input
Ubuntu / Debian	Yes	Same rule; ensure user in input
openSUSE	Yes	Same
Immutable / containerized Chrome (Flatpak/Snap)	Yes, but…	Extra sandboxing can still block /dev/hidraw*. Prefer distro-native Chrome/Chromium if Flatpak still fails after udev

Quick checklist

• User is in group input
• udev rule installed for 32c2 / 0026 (and 0025 if using dongle)
• udevadm control --reload-rules && udevadm trigger
• Device replugged
• hidraw nodes are root:input mode 660
• Chrome fully restarted
• Connect again on https://m1.tmkb.com/

References

• Device vendor ID: 32c2
• Products seen in the wild: 0026 (OM6239 TMKB-M1), 0025 (HS6209 receiver)
• Config HID usage page: 0xFF0F, usage 0x0001, report ID 14