SUMMARY When I've logged in to Plasma 5.14.3 from lightdm 1.28.0-2 in Fedora 29, I've seen the notification pop-up "Filesystem is not responding Filesystem mounted at '/' is not responding" in the bottom-right of the screen. That message also showed up in Notifications in the Status & Notifications applet. The notification sometimes showed a different partition I have mounted like /mnt/sda2 instead of / . The filesystems are functioning normally. The notifications haven't indicated any actual problem with the partitions from what I could tell. STEPS TO REPRODUCE 1. Logged in to Plasma 5.14.3 in Fedora 29 2. The notification "Filesystem mounted at '/' is not responding" appeared 3. Clicked on Status & Notifications applet > Notifications OBSERVED RESULT The notification "Filesystem mounted at '/' is not responding" appeared in the bottom-right of the screen and in Notifications in the Status & Notifications applet. EXPECTED RESULT No notification that the / filesystem is not responding should appear. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 29 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 ADDITIONAL INFORMATION The commit at https://phabricator.kde.org/R120:e1c19ce4daf92a14dee44b44d199672034a346c0 added lines 552-584 to plasma-workspace/dataengines/soliddevice/soliddeviceengine.cpp which could produce the notification I've been seeing on lines 557-558 KNotification::event(KNotification::Error, i18n("Filesystem is not responding", path), i18n("Filesystem mounted at '%1' is not responding", path)); plasma-workspace/dataengines/soliddevice/soliddeviceengine.cpp is at https://phabricator.kde.org/source/plasma-workspace/browse/master/dataengines/soliddevice/soliddeviceengine.cpp$27 That commit was discussed in https://phabricator.kde.org/D14895 plasma-workspace or solid might be a more appropriate component for this report. The closest components that I could find were Plasma Workspace Wallpapers and frameworks-solid, and I wasn't sure if those were appropriate. I left the version above as master because 5.14.3 was not shown in the list.
These notifications have been less frequent in the last few days. The notifications might've occurred if the log in time takes longer than the QTimer timer's timeout length in lines 554-558 of plasma-workspace/dataengines/soliddevice/soliddeviceengine.cpp QTimer *timer = new QTimer(this); timer->setSingleShot(true); connect(timer, &QTimer::timeout, [path]() { KNotification::event(KNotification::Error, i18n("Filesystem is not responding"), i18n("Filesystem mounted at '%1' is not responding", path)); }); Increasing the timeout length might stop the notifications. Is there a way I could increase the timeout duration? My partitions are all on drives inside or attached to the computer so the connection timeout checks might not be necessary in my case. Is there an option to disable the filesystem connection timeout check?
Imho that notification is pointless and should be removed, it's mostly meant for when a NFS mount becomes stale.
(In reply to Kai Uwe Broulik from comment #2) > Imho that notification is pointless and should be removed, it's mostly meant > for when a NFS mount becomes stale. I don't have an NFS or other network mounted partitions. Removing the notification would be fine from my perspective. My computer is old so the time that Plasma has taken to start seemed to be longer than the timer's timeout duration in most cases. I've also seen these notifications for /boot and /home.
Created attachment 117843 [details] screenshot showing the notification I see the same notification randomly on my system. Plasma freezes during a few (~10) seconds immediately after login and unfreezes when the notification shows up or a few seconds later even without the notification. I have no network mount point in my fstab file. Operating System: Arch Linux KDE Plasma Version: 5.14.90 KDE Frameworks Version: 5.54.0 Qt Version: 5.12.1
Same here. I use NFS but the notification is about local filesystems (/var and /tmp).
FOR PEOPLE EXPERIENCING THIS: THIS NOTIFICATION ONLY MEANS KDE TOOK MORE THAN 15 SECONDS TO COMPUTE THE FREE SPACE ON A FILESYSTEM. This may indicate an issue (though maybe not necessarily). I saw such a notification on my previous session start. I did not get it at the start of my current session. I am not saying this is a bug, as the taskbar took a lot of time to appear in my previous session, so something was wrong. Unfortunately, the only thing unusual I see in my logs is the following from syslog: Jul 16 23:44:14 vinci at-spi-bus-launcher[1581]: dbus-daemon[1913]: Failed to activate service 'org.a11y.atspi.Registry': timed out (service_start_timeout=120000ms) I imagine the notification signals a problem, but I do not know if it's a software or hardware issue. This PC has been rather unstable for several months, but I don't know if that is due to Debian/KDE/Kubuntu or due to a hardware issue. Kubuntu 19.04 uses Plasma 5.15 and KDE Frameworks 5.56.0.
Yesterday I got this notification on Neon unstable edition. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.16.80 KDE Frameworks Version: 5.60.0 Qt Version: 5.12.3
Created attachment 122201 [details] journalctl output journalctl -b -p4
Getting it regulary for different partitions ('HD1', 'HD2', 'tmp', '/'). Same like #6: latte-dock needs a long time to start. There's no network mounted. My journalctl output: https://bugs.kde.org/show_bug.cgi?id=401088#c8 The qt.qpa.xcb: QXcbConnection error pointed me to another mount related problem: https://bugs.kde.org/show_bug.cgi?id=389479 Operating System: openSUSE Tumbleweed 20190814 KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.60.0 Qt Version: 5.13.0 Kernel Version: 5.2.8-1-default OS Type: 64-bit Processors: 4 × Intel® Core™ i5-6500T CPU @ 2.50GHz Memory: 15,5 GiB
Maybe here's the problem? 2019-08-10T18:03:11.970045+02:00 mypc dbus-daemon[1248]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.9' (uid=0 pid=1383 comm="/usr/sbin/NetworkManager --no-daemon ") 2019-08-10T18:03:11.970274+02:00 mypc dbus-daemon[1248]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found. 2019-08-10T18:03:25.255828+02:00 mypc kdeconnectd[2071]: kdeconnect.plugin.notification: Not found noti by internal Id: "0|im.vector.alpha|61|null|10092" 2019-08-10T18:03:27.972131+02:00 mypc dbus-daemon[1248]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.9' (uid=0 pid=1383 comm="/usr/sbin/NetworkManager --no-daemon ") 2019-08-10T18:03:27.972239+02:00 mypc dbus-daemon[1248]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found. 2019-08-10T18:03:43.969303+02:00 mypc dbus-daemon[1248]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.9' (uid=0 pid=1383 comm="/usr/sbin/NetworkManager --no-daemon ") 2019-08-10T18:03:43.969526+02:00 mypc dbus-daemon[1248]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found. 2019-08-10T18:04:28.798981+02:00 mypc org_kde_powerdevil[2475]: powerdevil: Scheduling inhibition from ":1.12" "/usr/bin/falkon" with cookie 82 and reason "Video Wake Lock" 2019-08-10T18:04:28.799875+02:00 mypc org_kde_powerdevil[2475]: powerdevil: Scheduling inhibition from ":1.171" "/usr/bin/falkon" with cookie 83 and reason "Video Wake Lock" 2019-08-10T18:04:28.801993+02:00 mypc org_kde_powerdevil[2475]: powerdevil: Scheduling inhibition from ":1.12" "/usr/bin/falkon" with cookie 84 and reason "Video Wake Lock" 2019-08-10T18:04:28.802613+02:00 mypc org_kde_powerdevil[2475]: powerdevil: Scheduling inhibition from ":1.173" "/usr/bin/falkon" with cookie 85 and reason "Video Wake Lock" Got 2 desktop computers with the same system and this is part of the output from the troubled pc. There's a time gap which indicates that particular situation.
Not sure whether to create a new issue for this, but this is creating some serious annoyances for me, as I use my system to do complex Docker builds using BuildKit, causing many concurrent filesystem mounts and umounts. Each time I do this, I keep getting a ton of these (I expect the overlay got umounted before Plasma got around to checking it.) and I suspect they're slowing down Plasma for me, on top of being very annoying (it takes a while for all notifications to show up and disappear). It would be great if this check could be disabled entirely, selectively, or maybe just for known "uninteresting" mount locations such as Docker overlays.
(In reply to Filipus Klutiero from comment #6) > FOR PEOPLE EXPERIENCING THIS: THIS NOTIFICATION ONLY MEANS KDE TOOK MORE > THAN 15 SECONDS TO COMPUTE THE FREE SPACE ON A FILESYSTEM. This may indicate > an issue (though maybe not necessarily). if running the df command takes more than 15 seconds you sure have issues....
Created attachment 127968 [details] journalctl - Full log since SDDM to plasmashell completes
Created attachment 127969 [details] journalctl - Plasmashell log entries only since SDDM to plasmashell completes
Hi, I started getting this issue since I upgraded to Plasma 5.18.4 a couple of days ago. Never had this issue before. I tried with another user in the same computer, and it does the same thing. I'm attaching my logs since the moment I log in to SDDM until plasmashell completes loading. For the sake of simplicity, I'm attaching two files journalct-full.log containing all the logs, and journalctl-plasmashell.log containing the logs just for plasmashell. As you can see the logs, there is jump from 21:30:09 to 21:30:34 at the end of both files. If you need me to do any tests that helps find the root cause, please let me know. Thank you! -- Operating System: Arch Linux KDE Plasma Version: 5.18.4.1 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.2
I'm seeing the same issues on Arch Linux. This is a fresh install, 2 days old. I've been working on trying to trace the problem for this. System information: Operating System: Arch Linux KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.2 Kernel Version: 5.6.7-arch1-1 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700T CPU @ 2.80GHz Memory: 15,5 GiB of RAM The warning of "Filesystem mounted at "x" is not responding" appears from time to time after boot. I believe this is only a SYMPTOM and not the problem. My setup uses multiple disks: NVMe for root, SDD for other stuff and an HDD for archives. In the 3 years I'm running KDE (thru Gentoo, Kubuntu, Fedora, Debian and now Arch) I've never had problems with a slow start of Plasma. Free space calculation by df is instant: tim@sky> time df Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 8121464 0 8121464 0% /dev tmpfs 8148440 78328 8070112 1% /dev/shm tmpfs 8148440 12904 8135536 1% /run tmpfs 8148440 0 8148440 0% /sys/fs/cgroup /dev/dm-0 241725980 37445636 191971616 17% / tmpfs 8148440 12 8148428 1% /tmp /dev/mapper/ssd 244182200 128572228 113760108 54% /var/lib/libvirt/images /dev/mapper/ssd 244182200 128572228 113760108 54% /home/tim/Pictures /dev/mapper/ssd 244182200 128572228 113760108 54% /var/lib/docker /dev/mapper/hdd 732558200 129478868 601648348 18% /home/tim/Videos /dev/mapper/hdd 732558200 129478868 601648348 18% /home/tim/Archive tmpfs 1629688 4 1629684 1% /run/user/1001 tmpfs 1629688 12 1629676 1% /run/user/1000 df 0.00s user 0.00s system 70% cpu 0.006 total In order to further rule out the suggestion of free space calculation taking long, I've disabled all other disks but root in /etc/fstab and /etc/crypttab. Including swap. Leaving only the NVMe root partition: tim@sky> lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 232.9G 0 disk sdb 8:16 0 698.7G 0 disk nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p1 259:1 0 234.5G 0 part │ └─luks-2d922197-ec31-4ef6-864d-ebb772698177 254:0 0 234.5G 0 crypt / └─nvme0n1p2 259:2 0 4G 0 part This did not make any difference. So I installed systemd-bootchart to see what's "hanging". I've disabled all system services not needed for this test. Also, I created a new user account without customization. Logged it in once to initialize the home directory. Configured "Auto Login" in sddm for this test user. If you observe attached bootchart you'll see the following data: - At 4.2 seconds: "plasmashell" starts - For 2.1 seconds there is actual cpu activity - At 6.3 seconds: "plasmashell" seizes all cpu activity. Except for systemd-bootchart there is no other resource utilization. - At 19.5 seconds:, a single IO write. Probably a sync operation and unrelated to plasma. No other IO operations are done during the freeze period. - 30.9 seconds into boot plasma continues to have activity. - 31.8 seconds into boot Dolphin starts. This was a manual action by me to mark that the panel appeared in plasma. I used KSystemLog to filter and extract the plasmashell logs. I will attach it also, but did not find what causes the freeze. It does show that there is also a freeze period in output. My conclusion: this is not a system performance problem. Plasmashell freezes during start for no apparent reason. It is a static freeze of ~25 seconds. Which is also what Musikolo noted in his comment.
Created attachment 127993 [details] Bootchart
Created attachment 127994 [details] Plasmashell log
I would also like to note: Applications that are automatically started, do so without delay. For instance, if I shutdown with Firefox and Yakuake terminal, they are available as soon as the desktop shows. During the plasmashell freeze I can interact with them without problems or delay.
Created attachment 128091 [details] strace_kstart5_plasmashell.log Hi guys, I've been looking into the issue with plasmashell, this is what I found: 1.- I stop it with: kbuildsycoca5 && kquitapp5 plasmashell 2.- I start it with: strace kstart5 plasmashell As you can see at the very end of the attached strace_kstart5_plasmashell.log file, there are a bunch of error with SystemLoadViewer plasma, then it does nothing for ~24 seconds, and then it prints the following error and plasmashell shows up: trying to show an empty dialog file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:146:19: QML Loader: Binding loop detected for property "height" file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:146:19: QML Loader: Binding loop detected for property "height" I wonder whether the "Binding loop" error found in the Desktop.qml file could be the root cause. That file belongs to the plasma-desktop 5.18.4.1-1 package in ArchLinux. I hope it helps! Thanks.
I've pulled some updates yesterday and today (Arch linux) and this included some QT libraries. Not sure which one is was the culprit. Today on reboot plasmashell started just fine and without delay :). QT version is still the same and Plasma version is still the same. This were just some minor updates.
I can confirm that the delay is gone with the latest packages installed (Arch).
Yes, I can confirm the same thing. After updating to the latest packages in ArchLinux, it's working fine now! I saw new version of plasma-desktop (from 5.18.4.1-2 to 5.18.5-1) which contains plasmashell. This is the only relevant thing I found that could have any relationship with previous bug. Thank you all!
Hi, i'm experiencing the same problem with fedora31 and zawertun cop repo (https://copr.fedorainfracloud.org/coprs/zawertun/kde/) After upgrading to the latest packages, the error appeared. This is directly after logging in to plasma, you have a long delay and finally you get the error concerning /, /home or /boot (this is the varying part, the delay an the error message are constantly there) What i did to get rid of the error: - disabled zawertun copr repo - dnf downgrade kf5\* - dnf downgrade qt5\* --best --allowerasing - dnf upgrade the only remaining zawertun packages are (not important for this demo) # dnf list installed | grep zawert breeze-cursor-theme.noarch 5.18.5-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde breeze-gtk.noarch 5.18.5-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde breeze-icon-theme.noarch 5.70.0-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde kde-style-breeze.x86_64 5.18.5-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde oxygen-sound-theme.noarch 5.18.5-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde pam-kwallet.x86_64 5.18.5-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde phonon-qt5.x86_64 4.11.1-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde plasma-desktop-doc.noarch 5.18.5-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde xsettingsd.x86_64 1.0.0-1.fc31 @copr:copr.fedorainfracloud.org:zawertun:kde reboot system (now with plasma 5.17.5 and kf5 5.68) and all is fine, no login delay, no error messages So, this definitely has sth to do with the latest plasma upgrade Strangely enough, i also have another laptop running the latest zawertun updates without any problems at all
i did another test on the machine showing the error: upgrade to fedora32 (without zawertun copr repo) reboot, all is fine, instant plasma load after login enabling zawertun repo dnf upgrade --refresh login into plasma.... there you got the error again. The way back is a bit more complicated: dnf downgrade kf5\* ... test again, error still there, so get back even further: that is, downgrade all individual programs of the zawertun repo (something like: dnf list installed | grep zawertun | cut -d " " -f1 > zawertun then create a nice 'dnf downgrade ....' job out of the files contents So, what i have learned is: - the upgrade of the plasma apps from 19.12.3 to 20.04.0 seem to be the problem? Any help is appreciated
i tried a fresh install of fedora32 on kvm - just to be sure, that no additional repos are involved in this error initial install/startup plasma: all fine update to newest plasma builds dnf copr enable zawertun/kde && dnf update --refresh reboot, login: plasma hangs for several seconds (~20 secs) when it's finally loaded, the message is displayed in notifications popup: Filesystem mounted at '/' is not responding
There had been other bug reports pointing to telepathy, but this is not installed on my test machines (fedora31, fedora32 and kvm/fedora32) Regarding the zawertun copr, this was (still is) a good source for getting the latest plasma/kf5 additions without compiling myself. But, this doesn’t seem to relate to this specific copr – as you can see in this bugreport. So, maybe this could be a general plasma problem? (or, to narrow it down, to the 20.04.x release of the apps?)
In case of slartibart70 this bug was caused by KDEConnect compiled with Bluetooth support. See this issue: https://bugs.kde.org/show_bug.cgi?id=411399. After I remove kde-connect & kdeconnectd from test VM - startup time was once again small.
Yesterday I saw this notification on neon unstable immediately after login. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.72.0 Qt Version: 5.14.2 Kernel Version: 5.3.0-45-generic
This happens every time I log in on a new install of Kubuntu: error messages sometimes refer to '/' or '/boot'. Unfortunately it freezes for over a minute before finishing the log in process and becoming usable. Linux/KDE Plasma: Kubuntu 21.04 KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel Version: 5.11.0-18-generic
This happens to me when I try to wake up my HDD which is connect to my pc's usb via a usb2sata cable. The HDD will rotate all the time but the dolpin stuck. System try notice me "Filesystem $HDDPATH is not repond". The only way I can do is unplug the HDD and plug again. Is there a way to kill the process? SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.15.32-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 4600U with Radeon Graphics Memory: 15.1 GiB of RAM Graphics Processor: AMD RENOIR
Saw this notification a few hours ago on login after cold boot. Operating System: Arch Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Graphics Platform: Wayland
Created attachment 154472 [details] two 'not responding' file systems after login This bug persists. Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Graphics Platform: Wayland
The dialog described above appears when the file system is unusually slow. This may indicate that the hard disk is about to fail or may have other causes. Therefore, this is not a bug, but a feature.
(In reply to ManuelBoe from comment #34) > The dialog described above appears when the file system is unusually slow. > This may indicate that the hard disk is about to fail or may have other > causes. This bug is unfortunately not limited to OSes hosted on HDDs.
Tim, can you clarify why this ticket was assigned to David Edmundson?
(In reply to Philippe Cloutier from comment #35) > (In reply to ManuelBoe from comment #34) > > The dialog described above appears when the file system is unusually slow. > > This may indicate that the hard disk is about to fail or may have other > > causes. > > This bug is unfortunately not limited to OSes hosted on HDDs. and not necessarily limited to the filesystem where the OS is installed either - in my case, $HOME and several network shares are NFS, and this bug gets triggered whenever the file server is under heavier load than usual - running AIDE, installing updates, etc. definitely NOT a "feature". a "feature" would be the option to limit whatever process fails with this message to local harddisks only.
Hum, thanks Mathias. But in that case, should this ticket be re-titled to be more general (not specific to "/")?
(In reply to Philippe Cloutier from comment #38) > Hum, thanks Mathias. But in that case, should this ticket be re-titled to be > more general (not specific to "/")? that is the weird bit - the popup usually complains about / even when / is on a SSD or NVMe and it's actually some /users/$USER or /shared/data that comes in via NFS and is dragging things down. Almost as if whatever is broken doesn't even notice that someting is mounted somewhere under /users/ or similar.
Operating System: Slackware64-current KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.1.28 (64-bit) Drives: Local Storage: total: 1.82 TiB used: 1.13 TiB (62.3%) ID-1: /dev/sda vendor: Western Digital model: WD10EZEX-22MFCA0 size: 931.51 GiB ID-2: /dev/sdb vendor: Western Digital model: WD10EZRX-00D8PB0 size: 931.51 GiB I have this problem. Not just with '/' but also with '/home/' and 'home/backup/' Filesystem Type Size Used Avail Use% Mounted on /dev/sda1 ext4 92G 40G 47G 46% / /dev/sda3 ext4 818G 499G 278G 65% /home /dev/sdb1 ext4 917G 623G 248G 72% /home/backup Today for example, it was just '/' and '/home/backup/'. I start my computer to runlevel 3 (CLI) and start KDE Plasma with startx. I do not use a GUI login. In one instance all the of the mounted locations came up. The system runs just fine, no issues. The 'df' command is fast real 0m0.012s user 0m0.007s sys 0m0.006s I will attach two screen shots, one showing today's, one showing all three mounts
Created attachment 158987 [details] Two mount points. Today's file system not responding '/' and '/home/backup/'
Created attachment 158988 [details] Three file systems not responding. Three file systems not responding, '/', '/home/', '/home/backup/'
I have been seeing this for every filesystem (3 local filesystems on 2 RAID1 arrays , 5 NFS mounts), every login. Appears new(ish), as in I'm tracking current plasma releases and I've only seen it in the last couple of updates. The NFS mounts are indeed slow, as the network is firewalled until opensnitch's GUI loads (or could be down entirely) and mounts are retrying in the background (i.e. mounted with -o bg) but the messages regarding local arrays are entirely incorrect - as verified by dropping (or booting direct to) a VT. Those inaccessible NFS background mounts also completely prevent dolphin from launching (or hang it if it's already open and they go down), as well as freezing parts of plasmashell itself (including the panel and notifications). The result is an unusable desktop for a few seconds until the NFS mounts succeed, followed by a flurry of 8 "filesystem not responding" popups... which only appear once the filesystem is no longer "not responding", by which time they are completely pointless. If the network is actually down, the desktop remains unusable until the background mounts time out and fail - which could be 5 minutes, or it could be _forever_ if they are hard mounts. This is not an acceptable user experience by any stretch of the imagination, and I know of no other UI or file manager that locks up completely if a single non-essential mount is down. IOW, the behaviour of plasma/kio WRT inaccessible / unresponsive / slow filesystems is utterly broken, and has been for years. Adding popups is not addressing the root problem in the slightest, doubly so if they don't appear until _after_ the cause is resolved.
Ed. There are symlinks pointing at the NFS mounts on 2 of the local filesystems involved (one of which is /), so #471044 may be related. Maybe.
Also see #412724, #474403, #454722, and #441077. Sigh.