"Open File" dialog box takes a long time to appear on all applications

On Ubuntu 14.04.

While using KeepassX, I tried to open a database with the Ctrl+O shortcut, but it appeared to crash with a non-responsive window. I then noticed the same behavior with Firefox, gedit, Eye of Gnome and nearly any application I have with an "Open File" dialog.

Upon restart, I tried it again and it still happens. Eventually, though, I found out that the dialog box just took a long time to appear and it just renders the application non-responsive before it does (making it look like it crashed). It only happens the first time, though. Subsequent usage of Ctrl+O won't slow down anymore on an already running application that has already gone through that slow sequence once, but it does happen again (still only the first time the dialog box is called) once the application is restarted.

Using eog to test, when I ran it on a terminal and used the Ctrl+O shortcut. The following output appears right before the dialog box does:

Error creating proxy: Error calling StartServiceByName for org.gtk.Private.UDisks2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)

I tested multiple applications on a terminal with the same effect. I also noticed that running applications as root does not have the same effect, though. That is to say that the slow looks-like-it's-crashing behaviour doesn't happen when using those applications with sudo. From that output, I can infer that it probably has something to do with uDisks since I have partitions and drives mounted at startup. I also feel like uDisks has something to do with it because I've tested that this only happens if my external drives are plugged in before I'm logged in.

Closest thing I can find about the problem elsewhere is this rather cryptic comment on SourceForge about it happening to another application (that I don't have or use) saying:

... turns out that gtk doesn't like to run as a forked child orphan process - go figger...

What can possibly be the reason as to why this happens? Is there anything I can do to get rid of the slowness?

Solution 1:

I have the same problem when running gedit on Windows 10.

The problem started when I started working from home using a VPN to connect to the network and shared drives at work.

The problem turned out to be the shared drives: The file dialog process scans the shared drives before showing the file dialog window.

Because I access the shared drives over a VPN, scanning them takes a very long time; around 10 seconds.

There is a bug report for this: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1820866