File dialog extremely slow scanning network mounts

[John Bester]

From any application where you have a "save as" or "open" option, the dialog displays, but it takes forever. I have a i5 with 16GB RAM and 2 SSD's, so the machine is not slow. However, if I use gedit and click open / Other documents it takes 6 to 7 seconds before the file dialog is properly displayed. This does not even get better with reuse. I opened gedit just now and the first time it took 7 seconds. Then I pressed Cancel and repeated the process - it still took more than 6 seconds before the dialog was properly displayed. Often I would only see "Other locations" and then default places (Home, Documents etc) and bookmarks (I have about 8 bookmarks of which 2 are network shares) are displayed. These items are added one by one - maybe one every half second. Often it takes a few seconds before the first location other than "Other Locations" is displayed. Even the file panel is not immediate at first and you can see how lines are added one by one. Take into account that my home folder is on an SSD, so populating a file list should be lightning fast. I have looked at the CPU activity, but it does not go over about 10% during display of open and close dialogs.

Just be aware that this is not specific to gedit - all applications using gnome file dialog has the same problem.

Please see the attached screen recording.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gnome-shell 3.28.3-0ubuntu0.18.04.4
ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
Uname: Linux 4.15.0-46-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue Mar 19 16:14:16 2019
DisplayManager: gdm3
GsettingsChanges:
 b'org.gnome.shell' b'enabled-extensions' b"['<email address hidden>', '<email address hidden>', '<email address hidden>']"
 b'org.gnome.shell' b'command-history' redacted by apport
 b'org.gnome.shell' b'favorite-apps' redacted by apport
 b'org.gnome.desktop.interface' b'gtk-im-module' b"'gtk-im-context-simple'"
 b'org.gnome.desktop.interface' b'clock-show-date' b'true'
InstallationDate: Installed on 2018-12-02 (107 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

[Daniel van Vugt (vanvugt)]

It looks like the file dialog is being slowed by scanning network shares. Please try removing those (temporarily) and tell us if the problem goes away.

Please also reproduce the problem and then run:

  dmesg > dmesg.txt

and attach the file 'dmesg.txt' to this bug.

[paraiko (paraiko)]

Not sure if this bug is still active, but I can confirm this behaviour on both 18.04 and 19.10 and also that it is (in my case) caused by a NFS share from /etc/fstab that disappeared without being unmounted first.

umount -f -l /<share> solved the issue, file open/save dialogs are work again after that.

It seems to be specific for the GTK open/save dialog. When I for instance change the dialog in libreoffice to the native non-GTK dialogs, the problem disappears in this application.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Geert Linders (glinders)]

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.

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

Accessing the shared drives using Windows Explorer and other file operations (like copy) also take very long.

[Gao Shichao (xgdgsc)]

This makes me dought do Ubuntu devs actually use Ubuntu.

[Daniel van Vugt (vanvugt)]

Please check if the bug still occurs in a newer version of Ubuntu:

   https://ubuntu.com/download/desktop

If it does then please next open a GTK bug for the issue here:

  https://gitlab.gnome.org/GNOME/gtk/-/issues

[John Bester (john-bester)]

Ubuntu 20.04 does not have this problem any more. I did a few tests (even shutting down the server for which I had a share bookmarked). The various different scenarios I tested all behaved as I would expect.

[Karl Kastner (kastner-karl)]

I have the same problem on Ubuntu 20.04.2 LTS since a couple of days, esp. in libreoffice and evince. Sometimes I have to kill the applications. The problem occurred out of the blue.

[Daniel van Vugt (vanvugt)]

Karl,

This bug is closed so please open a new bug to discuss any remaining issue.