When I run X apps from the command-line (e.g. leafpad; most apps), I receive the following warning on the console:

 ... dbind-WARNING **: ... Couldn't register with accessibility bus: Did
not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the 
reply timeout expired, or the network connection was broken.

(line broken to fit the column width.)

Why am I getting this message and what can I do about it? The apps issuing it seem to be working fine.

This appears on Ubuntu 18.04 and Devuan 3.0 Beowulf (~= Debian Buster)

2 Answers 2


Put this:

export NO_AT_BRIDGE=1 

someplace where it gets run, e.g. in /etc/environment or your ~/.bashrc / ~/.bash_profile.

This workaround is suggested in this wiki page (in German) or here (in English), but I don't really understand why it's needed or what it really does, so caveat emptor.

  • 4
    Does this just suppress the error or actually solve the problem? I'm having trouble understanding what this does.
    – algae
    Jan 6, 2021 at 22:09
  • 1
    @algae: It doesn't suppress the error. i.e. it's not like redirection to /dev/null. But I can't say that I know what's going on.
    – einpoklum
    Jan 6, 2021 at 23:27
  • 1
    Thanks @einpoklum, in the end it didn't help my situation despite having the same warning message.
    – algae
    Jan 8, 2021 at 0:02
  • 2
    @algae: ATK is the GNOME accessibility bus. It's (I think) designed to allow things like screen readers and other accessibility hardware to work. But if you don't have any such devices, communication over the bus doesn't go anywhere and the system displays a message telling you so. The environment variable tells your app to not attempt to use ATK at all.
    – David C.
    Feb 28, 2022 at 20:54
  • 2
    @DavidC.: But why do apps need to be told that? I mean, it should be the typical case for nothing to be happening on that bus, so that even if apps don't find it / don't get a reply on it - that should be considered normal.
    – einpoklum
    Feb 28, 2022 at 21:11

Glad you've figured out an answer yourself; here's some more context to answer the "why" in comments.

I've got this error in a setup like so. Using 2 laptops (one with Kubuntu for work, another I personally own, with Arch) — I've got somewhat lazy, and instead of physically picking up the other laptop, used X11 Forwarding a.k.a. ssh -X.

Detour: X11

Conceptually, X11-forwarding is a "remote desktop" technology, like VNC, RDP... but with a twist. It doesn't do a video-stream of the remote desktop; instead, it rides the networked architecture of X11 protocol.

Back in the days of X11 conception (1980-s!), all screens and keyboards were "remote": one huge mainframe cabinet was running the OS processes backing GUI apps of many users (typically all computing users in an organization owning that mainframe computer). As a consequence, in X11 pixel drawing parts are done client-side.

  VNC-style remote desktop                              X11 forwarding
  ────────────────────────                              ──────────────

┌─────[Client machine]──────┐        ┌──────[Client machine]────────────────────────────────┐
│                           │        │                                                      │
│  Runs VNC viewer app      │◄──┐    │ - Runs X server                                      │
│                           │   │    │ - Runs local GUI apps, i.e. those using DISPLAY=:0   │
│  • remote GUI embedded in │   │    │ - Renders remote GUI apps which X11-connect to it,   │
│    VNC viewer window      │   │    │   to network address like  client.local.lan:0        │
│                           │   │    │   Usually nowadays, ssh -X secures the X11 traffic   │
└───────────────────────────┘   │    │   by tunnelling it; so e.g. DISPLAY=localhost:10.0   │
                                │    │   This localhost is interpreted by app running on    │
                         network│    │   the server machine!                                │
                                │    │   Because SSH tunnel.             ┌─────┐   ┌─────┐  │
┌─────[Server machine]──────┐   │    │                           ┌──────►│ GUI │ … │ GUI │  │
│                           │   │    ├───────────────────┐◄──────┘       └─────┘   └─────┘  │
│  Runs VNC server app      │◄──┘ ┌─►│ SSH tunnel egress │                local X11 server  │
│                           │     │  └───────────────────┴──────────────────────────────────┘
│  • streams pixels of the  │     │
│    entire screen          │     │  ┌──────[Server machine]────────────────────────────────┐
│  • receives client input, │     │  │                                                      │
│    forwards it to GUIs    │     │  │ - May lack any screens, input devices, GPUs          │
│                           │     │  │ - May not run any X server                           │
│ ┌─────────┐   ┌─────────┐ │     │  │ - Yet, runs remote GUI apps, as OS processes         │
│ │ GUI app │ … │ GUI app │ │     │  │ - GUI stuff lives on client machine's X server       │
│ └─────────┘   └─────────┘ │     │  │ - Painting commands and input events                 │
│                           │     │  │   travel within the X11 connection.                  │
└───────────────────────────┘     │  │                                                      │
                                  │  │                                   ┌─────┐   ┌─────┐  │
                                  │  │                           ┌──────►│ app │ … │ app │  │
                                  │  ├────────────────────┐◄─────┘       └─────┘   └─────┘  │
                                  └─►│ SSH tunnel ingress │                 OS processes    │

In the common use-case of personal computer, the X-server and client-GUIs run on the same machine, so this funny X11 protocol runs over localhost mostly invisibly.

But it also works over real network, and surprisingly well! Especially if supplemented with ssh's built-in compression, -C. For example, I can run Brave (a Chromium-based web browser) "remotely" with ssh -CX pasocon.local brave, and it's pretty much usable over WiFi.

Detour: accessibility on Linux desktop

Won't say much, not an expert here, barely familiar at all. But I'll say 2 things.

First, observe how much more amenable to assistive technologies X11 forwarding architecture is, in principle. E.g. screen-reading a raw video-stream of remote desktop, (though AI tech may fix that some day), is significantly more challenging than screen-reading an X server state or event/command stream. Via X11 protocol, apps will say hey X server, paint a text "Lorem ipsum" in this font at these coordinates; change this button's color; collapse this menu, etc.

Second, notice how most of shenanigans around handling input to embedded desktop in VNC/RDP style (focus-grabbing, escapes for special key combos a-la Ctrl-Alt-Del, correctly remapping keyboard layout, the clipboard, etc etc) simply go away in X11-forwarding. On the client machine, the remote GUI is actually as "local" as it can be. My KDE Plasma doesn't even distinguish X11 forwarded Cinnamon windows from local KDE ones in the Alt-Tab interface.

Detour: Freedesktop D-Bus

Really briefly, D-Bus is an RPC (Remote Procedure Call) framework in object-oriented style. It's used extensively on linux desktop (but far not only). For some examples, the NetworkManager provides a dbus service; it's relatively easy to write an app talking to it over dbus to view and manipulate those network connections, or get callbacks when system connectivity changes. Desktop notifications (those popups from email, messengers, browser apps, etc) are a widely integrated org.freedesktop.Notifications D-Bus service. Ayatana Indicators (tray icons) work over D-Bus too. There's much more.

It makes perfect sense to provide the extension-point for accessibility assistive-tech on D-Bus, too.

Having written code that works with D-Bus, I can tell 100% without doubt, that this error message talks about a D-Bus method call failure:

... the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Combining the above, I can guess why export NO_AT_BRIDGE=1 helps in my case. I'm X11-forwarding a Cinnamon (GNOME derivative) application into a KDE desktop. It'd be silly to expect D-Bus instances of the two desktops to magically connect, X.Org isn't coupled to D-Bus AFAIK. Thus, I hit some obscure corner-case in "AT_BRIDGE" (AccessibilityToolkit Bridge?) of GTK... whatever that is. Disabling it works around the issue for me.

Not sure, of course, how much of this applies to the issue in original question. But, there you go, a bit of context about the apparently related moving parts. HTH

You must log in to answer this question.

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