Terminal and Nautilus stopped working after a crash

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.

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.

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.