Bug 505069

STEPS TO REPRODUCE
1. Ensure an SMB share is mounted via fstab. My fstab line is:
   //192.168.X.X/share_NAS /mnt/share_NAS cifs defaults,nofail,_netdev,credentials=/route/credentials 0 0

Scenario A: Dolphin is already open when the network connection to the SMB share is lost.
2. Open Dolphin (you can be Browse any location, local or remote).
3. While Dolphin is open, disconnect the network path to the SMB server (e.g., activate a VPN that makes the server unreachable, or shut down the SMB server).
4. Attempt to interact with Dolphin (e.g., click on any folder, local or remote; refresh the view; navigate back/forward; or simply click on Dolphin's window).

Scenario B: Dolphin is not open when the network connection to the SMB share is lost.
2. With Dolphin closed, disconnect the network path to the SMB server (e.g., activate a VPN that makes the server unreachable, or shut down the SMB server).
3. Attempt to launch Dolphin.


OBSERVED RESULT
Scenario A: Dolphin is already open when the network connection to the SMB share is lost.
Dolphin freezes completely for at least 1 minute, making the entire application unresponsive. Trying to interact with Dolphin (e.g., clicking on any folder, even local ones) causes it to freeze again for at least 1 minute for each interaction, even if it is with local locations. The interface often turning gray and displaying "(Not Responding)". This unresponsiveness affects the entire Dolphin application, including local file Browse.

Scenario B: Dolphin is not open when the network connection to the SMB share is lost.
Dolphin takes approximately 2 minutes and 40 seconds (2:40) to launch. After finally opening, the behavior described in Scenario A (freezing when interacting with any folder, even local ones) is observed.


EXPECTED RESULT
Dolphin should ideally handle the lost network connection gracefully. It should either:
- Fail quickly with an error message (e.g., "Connection lost," "Share unreachable").
- Show a loading indicator without freezing the entire application, allowing the user to interact with other parts of Dolphin or the desktop.
- Prompt the user with options to retry or cancel.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.7-arch2-1 (64 bits)
Graphics Platform: Wayland


ADDITIONAL INFORMATION
This issue occurs on a fully updated Arch Linux system (sudo pacman -Syu has been performed).

Troubleshooting steps already taken:
- The soft mount option is already set in the fstab line.
- net.ipv4.tcp_retries2 has been set to 3 via sysctl.
- "Show previews for remote files" is disabled in Dolphin settings.
- Other fstab options beyond the basic defaults,nofail,_netdev have been tested without resolving the issue. The full fstab line used is:
  //192.168.X.X/share_NAS /mnt/share_NAS cifs uid=1000,gid=1000,nosuid,nodev,nofail,_netdev,soft,x-systemd.automount,credentials=/route/credentials,x-gvfs-show,x-gvfs-name=share_NAS 0 0

Comparison with other file managers:
- Nautilus: Does NOT freeze. It opens and functions normally with local locations. Attempting to access the affected network drives does not block the application; it only shows a "loading..." message, allowing the user to interact with the application immediately.
- Thunar and Konqueror: Also freeze like Dolphin in this scenario.

This appears to be a recurring issue for Dolphin/KIO when dealing with unavailable network shares. I've noted that older bug reports like ID 435940 (closed as WORKSFORME) and ID 316655 (RESOLVED UPSTREAM) are closed, but the problem persists in my current, updated system. I've also seen other active reports (e.g., ID 445065, ID 500671) describing similar freezing behavior with SMB in Dolphin. Please consider this report as a current manifestation or potential regression of this long-standing problem.