I have a USB Zigbee dongle, but I'm unable to connect to it. It briefly shows up in /dev/ttyUSB0, but then quickly disappears. I see the following output in the console:

$ dmesg --follow
[  738.365561] usb 1-10: new full-speed USB device number 8 using xhci_hcd
[  738.607730] usb 1-10: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[  738.607737] usb 1-10: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[  738.607739] usb 1-10: Product: USB Serial
[  738.619446] ch341 1-10:1.0: ch341-uart converter detected
[  738.633501] usb 1-10: ch341-uart converter now attached to ttyUSB0
[  738.732348] audit: type=1130 audit(1632606446.974:2212): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=brltty-device@sys-devices-pci0000:00-0000:00:01.3-0000:03:00.0-usb1-1\x2d10 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  738.768081] audit: type=1130 audit(1632606447.007:2213): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=brltty@-sys-devices-pci0000:00-0000:00:01.3-0000:03:00.0-usb1-1\x2d10 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  738.776433] usb 1-10: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[  738.783508] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[  738.783521] ch341 1-10:1.0: device disconnected
[  739.955783] input: BRLTTY 6.4 Linux Screen Driver Keyboard as /devices/virtual/input/input35

4 Answers 4


The problem here is BRLTTY, a program that "provides access to the Linux/Unix console (when in text mode) for a blind person using a refreshable braille display".

If you are not blind, you can disable BRLTTY in two different ways:

Remove udev rules

BRLTTY uses udev rules to get permissions to mess with the TTYs without being root. You can disable these rules by overriding the rules shipped by your distro with /dev/null:

for f in /usr/lib/udev/rules.d/*brltty*.rules; do
    sudo ln -s /dev/null "/etc/udev/rules.d/$(basename "$f")"
sudo udevadm control --reload-rules

Disable service

The BRLTTY service is launched by the brltty.path service. This service can be completely prevented from ever starting by running by doing the following:

$ sudo systemctl mask brltty.path
Created symlink /etc/systemd/system/brltty.path → /dev/null.
  • 4
    You can also just uninstall the whole thing. If you want to use any USB-serial device, another thing that you may want to purge is modemmanager (which is spamming any serial like with "commands" able to confuse or even brick any device which is not a kind of AT-modem).
    – user313992
    Commented Sep 26, 2021 at 7:33
  • 1
    Unfortunately, on Arch Linux, I can't :(. QEMU depends on brltty. But that is a good solution for folks on other systems!
    – flaviut
    Commented Sep 26, 2021 at 16:41
  • 2
    On my Manjaro I disabled all brltty* services (listed by autocompletion) to get it to work, disabling only brltty.path didn't help.
    – EvgEnZh
    Commented Oct 22, 2021 at 20:21
  • @EvgEnZh thanks for sharing, and that comment sounds like an answer to me! Feel free to post it as one, I'm sure other folks would appreciate it too!
    – flaviut
    Commented Oct 25, 2021 at 14:17
  • 1
    QEMU's dependency on brltty has semi-recently been made optional so you can now remove it with QEMU installed Commented Jan 20, 2022 at 23:20

Shooting down a bit too much there. A much less invasive solution was contributed by user Blackisle to this post ("Arduino not working adter brltty update") on ArchLinux BBS.

brltty has a rule for idVendor=1a86, idProduct=7523, which is the same as the CH340 serial converter on my Mega clone.

You can see your device id by using lsusb to get a list of your devices (unplug your Arduino, run lsusb then plug in your Arduino and run lsusb again to see which device appears).

In my case:

Bus 003 Device 005: ID 1a86:7523 QinHeng Electronics CH340 serial converter

Take a note of the ID and then open the brltty rules file:

sudo nano /usr/lib/udev/rules.d/90-brltty-device.rules

Search through the file until you find the entry for your ID:

# Device: 1A86:7523
# Baum [NLS eReader Zoomax (20 cells)]
ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

Now comment out the line:

# Device: 1A86:7523
# Baum [NLS eReader Zoomax (20 cells)]
# ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

Save and close the file then reboot.

After the reboot the /dev/ttyUSB0 port was available again in the Arduino IDE.

  • 9
    This is great, especially for folks who do need this brltty service! As a side note, you can reload the udev rules without a reboot by running sudo udevadm control --reload-rules.
    – flaviut
    Commented Dec 7, 2021 at 22:45
  • That's cleaner and worked perfectly, thanks.
    – ryancey
    Commented May 5, 2022 at 23:10
  • I don't see how this is supposed to be "much less invasive", but ok. I think using systemctl commands to manage the service units is the way to go, especially since it exists to manage the very service units responsible for the conflicts.
    – code_dredd
    Commented May 6, 2022 at 19:41
  • 6
    A less invasive version is to copy the 90-brltty-device.rules file to /etc/udev/rules.d/ instead, and do the edit there. That way it will not be overwritten in future updates.
    – D.S
    Commented Jun 17, 2022 at 19:35
  • 2
    This is together with reloading the udev rules as @user60561 explained in his comment is what works on Pop!_OS 22.04 (ubuntu 22.04).
    – calocedrus
    Commented Aug 26, 2022 at 13:28

This is just to highlight the excellent comment by @EvgEnZh and add a little something. There is more than just one service that needs to be disabled on Manjaro. For me it was the following:

List the services with:

 $ systemctl list-units | grep brltty
  brltty.path                             loaded active running   Default BRLTTY Instance
  [email protected]         loaded active running   BRLTTY Instance: /etc/brltty.conf
  system-brltty.slice                     loaded active active    Slice /system/brltty
  system-brltty\x2ddevice.slice           loaded active active    Slice /system/brltty-device

And then disable them with:

$ sudo systemctl mask brltty.path
$ sudo systemctl stop brltty.path
$ sudo systemctl mask system-brltty\x2ddevice.slice
$ sudo systemctl stop system-brltty\x2ddevice.slice
$ sudo systemctl mask system-brltty.slice
$ sudo systemctl stop system-brltty.slice
$ sudo systemctl mask [email protected]
$ sudo systemctl stop [email protected]

I'm not sure if all of them need to be masked, but just masking and stopping brltty.path did not work for me.

  • Nice, I like this. No need for extra files to modify and then track around/worry about. Thanks for posting.
    – Hendy
    Commented Dec 9, 2021 at 22:38
  • 1
    I used systemctl list-units | grep brltty to find that my system had brltty-udev.service running. Afterwards I used systemctl mask brltty-udev.service and then systemctl stop brltty-udev.service to stop the service. When I now connect my device, in my case a Wemos D1 mini, the /dev/ttyUSB0 is not disconnected anymore and I can see the port in the Arduino IDE. So different device, same method :).
    – Adriaan
    Commented Jun 17, 2022 at 19:45
  • I'm using Ubuntu 22.04, and needed to mask & stop the brltty-udev.service unit as well, as per above comment from @Adriaan
    – justinsg
    Commented Aug 24, 2023 at 1:54

Commenting out the offending lines in brltty worked for me too

I have quite a few usbuarts and it was very frustrating to find them all vanished but still working under previous Ubuntu and Windows!

from lsmod

Bus 001 Device 019: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 021: ID f055:9800 MicroPython Pyboard Virtual Comm Port in FS Mode

For safety I commented out both 10c4:ea60 and 10c4:ea80

But honestly I'm mad. Supporting our blind (or deaf, or wheelchair bound) friends is admirable.

How can they make a mistake like that. Taking down usbuarts from 3 different manufacturers. The CP210x is obviously a popular chip.

I was tempted to just delete 85-brltty.rules

Which is the exact opposite of what those who decided to add built in support for braille intended.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .