Something went terribly wrong and, after a C++ program I was working on crashed, my terminal and nautilus (files) stopped working.

I managed to install Terminator (another shell emulator), here is what I am getting when trying to start Terminal from Terminator:

(gnome-shell:779): Clutter-CRITICAL **: 01:49:35.532: Unable to initialize Clutter: Unable to initialize the Clutter backend: no available drivers found. (gnome-shell:779): mutter-WARNING **: 01:49:35.532: Unable to initialize Clutter.

Here is what I get when launching Nautilus (btw somehow I can launch it from Terminator but not by clicking the icon)

** (nautilus:445): WARNING **: 01:48:33.021: AT-SPI: Could not obtain desktop path or name ** (nautilus:445): WARNING **: 01:48:33.026: AT-SPI: Could not obtain desktop path or name ** (nautilus:445): WARNING **: 01:48:33.031: AT-SPI: Could not obtain desktop path or name

..... another 10-15 repetitions of that error ....

** (nautilus:445): WARNING **: 01:48:33.509: AT-SPI: Could not obtain desktop path or name ** (nautilus:445): WARNING **: 01:48:33.509: AT-SPI: Could not obtain desktop path or name

Any pointers on how I can get things back to normal?

EDIT: It does persist after reboot.

  • Perhaps a stupid question, but does this persist after a restart? Better add that to your question.
    – vanadium
    Oct 23, 2018 at 8:39
  • @vanadium Fair question! It does persist after the reboot, I have made the edit.
    – Rotkiv
    Oct 23, 2018 at 17:15
  • 1
    I just hit this as well, and submitted an issue report for it: bugs.chromium.org/p/chromium/issues/detail?id=988902 Jul 30, 2019 at 22:22

3 Answers 3


I started experiencing the same problems as you describe today, seemingly out of nowhere. I found my solution in this thread: https://forums.linuxmint.com/viewtopic.php?t=279168

(For posterity) First install Terminator or Xterm to get a working terminal. Open Synaptic Package Manager and install it there.

Check the permissions on the files in your home folder

find $HOME ! -user $USER

In particular be on the lookout for files in .dbus

You may resolve all permissions at once with

sudo chown -Rc $USER:$USER $HOME

Additionally, I removed the files in $HOME/.dbus/session-bus, removed Chrome Remote Desktop and its data in $HOME/.config/chrome-remote-desktop and rebooted. My assumption is that Chrome Remote Desktop restarted itself during an update and wrote some files as root in the home folder.

  • 3
    I think it MIGHT be chrome-remote-desktop in my case as well. Truly bizarre. Anyways. It works now. Thank you!
    – Rotkiv
    Oct 24, 2018 at 0:16
  • I'm glad it helped. You could check /var/log/apt/history.log and see if chrome-remote-desktop pops up in relation to an update of something else these past couple of days.
    – Michiel
    Oct 24, 2018 at 2:06
  • It happened to me again. This time just removing $HOME/.config/chrome-remote-desktop again fixed it. So there's definitely something to it.
    – Michiel
    Oct 25, 2018 at 15:18
  • This answer helps me also. I've upgraded the Ubuntu from 18.04 to 19.04 version and had installed chrome-remote-desktop app. Steps from the answer and reboot had fixed the problem.
    – voleger
    Jul 7, 2019 at 19:21

As the above answer mentions, the directory ~/.dbus/ is important. If it doesn't exist, create it.

If that doesn't help either, set the environment variable NO_AT_BRIDGE=1.


After working with the chromoting team through https://bugs.chromium.org/p/chromium/issues/detail?id=988902, here's what I've learned:

Gnome (and possibly XFCE and others) doesn't currently handle multiple sessions for the same user very gracefully.

In this case, adding Chrome Remote Desktop caused a default Gnome session to be created that could be connected to using the CRD client. Because this second session was created after the local session initially, all appears to be fine on the local session, and the issue might go completely unnoticed until the next reboot.

After a reboot, however, the remote session runs at startup, grabbing resources that would normally be used for the local session. This can include the dbus socket, the audio system, the user's keyring, and possibly others that I didn't find.

Since these are no longer available for the local session that starts later, any application or functionality that requires their use fails, and does so apparently silently unless you know where to find the relevant logs.

The recommended workaround for now is to configure CRD to use a different session type, for example by creating a ~/.chrome-remote-desktop-session file with the desired configuration.

The chromoting team have a patch they will roll out in a newer version that is expected to significantly improve the user experience.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.