QGIS is not responding when a network folder mapped to a local drive letter is not connected to the local network

[grik07]

The desktop application suddenly stops working, either when loading a project, a layer or any other module.

[gioman]

@grik07 3.1 or 3.10? Have you tried with a new QGIS profile?

[grik07]

I'm sorry, I mean QGIS 3.10.

[gioman]

@grik07 Have you tried with a new QGIS profile?

[grik07]

Yes, I already tried different profiles, but it still stops working

[roya0045]

Even with local layers ?

[relima]

This happens to me to.. constantly.

[roya0045]

Does it uses too much memory? Do you have a docking station?

[relima]

Ok! I found the problem that was causing my Qgis 3.10.1 to constantly freeze. My windows 10 machine had a network folder that was mapped to a local drive letter ( Z:\ ). However, I was not connected to my local network, so that drive letter was showing up the driver as "disconnected". For some reason, this really bothered Qgis, making it constantly become non-responsive. The solution was to remove the network mapped drive letter. It immediately fixed Qgis. It is very quick and responsive now.

[roya0045]

@relima this is what I was expecting. Thanks for the feedback!

[luipir]

For some reason, this really bothered Qgis, making it constantly become non-responsive. The solution was to remove the network mapped drive letter. It immediately fixed Qgis. It is very quick and responsive now.

IMHO is a local conf problem and the issue should be closed. If you agree @relima please close it!

[relima]

@grik07 - were you having the same problem as I? If so, can you close it or provide us with more info?

[rmarzocchi84]

@luipir I think it is a problem for a lot of people working with laptop where sometimes network folder are disconnected. I do not know the code of QGIS browser, but I think a "try-except" or a simple "if" sintax can solve this bug

[LuisAquatics]

@rmarzocchi84 @luipir This problem still exists from QGIS 3.6 until 3.14 - Startup / Window freeze if Network is disconnected
I now found a workaround without deleting the Network drive letter (in explorer?) as @relima suggestest above:

• Connect to your VPN/Network drive → QGIS should start up without problems

• in QGIS browser, right-click on the network drive and click "Hide from Browser"
  → QGIS will work as fast and without bugs as before, you can disconnect from VPN/network drive now

  

• If you want to show the hidden drive in the Browser again, go to
  Settings -> Options -> Advanced -> Browser -> hidden Paths -> edit the line or right-click -> delete setting

  

  otherwise drag-and-drop will workaround the browser problem completely

[rmarzocchi84]

Thanks for the suggestion

[joshuanunn]

Hi, this issue also appears to exist in the 3.4 LTS, and has been a massive pain point in a corporate Windows based environment. It's taken a long time to track down what is causing it, but for many of our users this is just seen as "QGIS is getting unusably slow" - the reality is that as more people are working from home (and not always on corporate VPN), this becomes more prevalent.

Maybe a naïve suggestion, but can a solution not be to populate the browser drive mappings based on whatever the cached OS state is, but to only attempt to query the drive(s) in question when a specific drive is "expanded" in the browser? This could be coupled with behaviour where the drives are always started collapsed (regardless of previous state on QGIS close)?

For now, we will mass-script the solution by @Bergwenzler above by modifying user QGIS.ini files in place to ignore everything except C/D, but this is not ideal!

Anyway, otherwise great software, but I do think this is a serious issue that warrants looking at!

[gioman]

a massive pain point in a corporate Windows based environment.

@joshuanunn maybe one of those corporate (that save thousands -or tens of- by not having to pay licenses) are interested in supporting the work for fixing this?

[joshuanunn]

a massive pain point in a corporate Windows based environment.

@joshuanunn maybe one of those corporate (that save thousands -or tens of- by not having to pay licenses) are interested in supporting the work for fixing this?

Hi @gioman I should clarify that "corporate" in this case does not mean huge (maybe 10-20 users), but I appreciate it does save on licensing.

I'm more than happy to help if I can?

[yuvalutilis]

Issue is still happening both on 3.16.1 & 3.16.2 . i don't want to hide the paths because when i work in the office i would like it to be available. so issue is occurring when working from home not on the office network. it solved when operating my VPN to the office.

[lueho]

I have the same problem in 3.16.3.
@Bergwenzler 's solution solved the problem for the most part. Before, QGIS froze at the loading screein already, when not connected to the VPN. However, when using the editor in the python console, QGIS still freezes, when not connected to the VPN. The freeze happens upon pressing the either of the "save" buttons or "run" even if the script files are stored locally and the script itself is only print("Hello world!"). I don't see how this is connected and can only report the phenomenon.

[Marwe]

Thank you so much for the hint to "hide from browser", which is useful on Linux, too!
I have the hanging dialogues since years and in many versions, and never really found the cuprit.

Hiding /snap on ubuntu helped immediately, also you may want to check things in /mnt, if you mount stuff there (davfs/Webdav mount points).

/snap may be relatively new, but since ubuntu started to deliver important software packages via snap, this is seen more widely these days.
If I understand correctly, this could be excluded by default, since it is a mechanism of snap internally. There is no need to ever interact with those mount points directly.

In previous distributions it might have been WebDAV mounts or gnome mounts (.gvfs), and I don't know exactly about docker mounts and other stuff that may be mounted (currently no blockers here), but it can help to scan mount for suspicious mount types.

/dev may be needed if you use GPS/serial.

[gomyhr]

I have the same issue with 3.18.1 not even starting. It was alluded to in #33164 (comment), but not mentioned explicitly in this thread that a workaround with the QGIS GUI is to edit QGIS3.ini to include
hiddenPaths=S:/, Z:/
(where S: and Z: are the misbehaving drives in my case) in the [browser] section. QGIS3.ini is normally located in C:\Users\<User>\AppData\Roaming\QGIS\QGIS3\profiles\default\QGIS on Windows (if additional profiles have not been added).

[Marwe]

Unfortunately the stalling is back for me/us, so hiding might not be the proper solution.
There is a thread on stackxc about it
https://gis.stackexchange.com/questions/281667/qgis-on-ubuntu-hanging-at-save-file-dialogue
with an interesting strace command for debugging.

[scottshambaugh]

I believe this was fixed in PR #43416 for QGIS 3.20, and can now be closed.

[gxiros]

Ok! I found the problem that was causing my Qgis 3.10.1 to constantly freeze. My windows 10 machine had a network folder that was mapped to a local drive letter ( Z:\ ). However, I was not connected to my local network, so that drive letter was showing up the driver as "disconnected". For some reason, this really bothered Qgis, making it constantly become non-responsive. The solution was to remove the network mapped drive letter. It immediately fixed Qgis. It is very quick and responsive now.

thanks a lot - this was the case for me also!

[cefect]

I'm having this issue on both my 3.26.2 and 3.22.8 installs (Windows 10 Version 2009). Which is a bit confusing because these have been working fine for some weeks and I haven't made any major changes to my system (or network state). Regardless, gomyhr's QGIS.ini fix works great (actually seems to start faster than I remember). I suggest re-opening this issue as it's quite problematic and doesn't provide any feedback to the user.

[9ls1]

I'm working on my office computer connected to several network drivers. I have access to all the drivers. I had the same issue with QGIS ver. 3.26.2: one day EVERY click made "QGIS not responding" for 10-20 seconds. I usually not use Browser panel, but this time I had activated it for some reason, but I didn't see the connection between Browser and painful slow QGIS, so I uninstalled the whole OSGeo4W, deleting relevant files and profiles before a fresh installation of ver. 3.26.3 from OSGeo4W. Just to discover the same issue since the Browser is appearing as default... Thanks to this, I got rid of the problem: Both closing the "Browser Panel" or hiding ALL network drives did the trick.

[aazuspan]

This issue still exists in 3.28.2 on Windows 10.

QGIS became very slow to open and run after I mapped and disconnected two network drives. The fix from #43416 doesn't seem to have helped since "Monitor for changes" was disabled on those drives. I was only able to fix performance by hiding them from the browser.

[DavidMatthews83]

@aazuspan I have been having the same issue on 3.28.2 windows 10 with a network drive. Would completely freeze if i tried to open it. Dropped back to a 3.20.3 version I also had installed and working ok.

[Marwe]

I finally found the culprit at least on Linux, which is at least in my case not related to QGIS, but GNOME:

I don't know if this one could be triggered on other platforms/IDEs, but in my case there is a deadlock situation with gvfsd-trash and dbus I run into, interestingly only triggered within QGIS, not in other software/dialogs (I am using GNOME as DE).

However, killing the gvfsd-trash process helps, though it can be automatically started later again and then needs to be killed again.
Here is the question and the underlying gvfsd-trash issue.

This command will make my life easier in future:
pkill gvfsd-trash

I defined an alias to quickly run it without needing to remember the details.