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.

My 2 cents here: I believe the issue is outside Plasma entirely and purely systemd related (more precisely systemd-fstab-generator related); I had the same errors described here since the upgrade to Plasma 6.0.x and I seem to have fixed the intempestive notifications by altering the parameters in fstab related to the nfs mounts.

Following line corresponds to my current settings in fstab and I was able to boot several times without having the random locations unavailable notifications; prior to the current set of parameters, for 90 seconds after the login, the plasmoids on the desktop appeared to be frozen (I have several showing the CPU frequency graphs, temperatures, hdd I/O). After the modification they behave normally right since the login.

Example of my current config (the relevant part):

> noatime,nofail,users,async,_netdev,retry=7,x-systemd.automount,x-systemd.after=network-online.target,x-systemd.device-timeout=50s,x-systemd.mount-timeout=90s,timeo=15,x-systemd.idle-timeout=2min 0 0

My changes:
- added async (the big help seems to come from this one)
- added _netdev (just making sure systemd-fstab-generator will correctly schedule the mount - after the network becomes available)
- added retry=7 (7 was my choice, it does not have a particular meaning for you)
- changed x-systemd.device-timeout=15 to x-systemd.device-timeout=50s (it appears necessary to specify time measure unit, systemd can be that picky)
- added x-systemd.mount-timeout=90s

Hopefully this can be your solution as well ...

(In reply to SoftExpert from comment #46)
> My 2 cents here: I believe the issue is outside Plasma entirely and purely
> systemd related (more precisely systemd-fstab-generator related)

Same problems occur with openrc, so I really don't see how it has anything to do with systemd.

I see your 2c, and raise you my own:
All of this has the same common cause, namely that Plasma can't handle slow system mounts (i.e. not KIO VFS) of any kind gracefully, because the  UI thread blocks on some filesystem call (likely a stat and/or something in solid collecting file metadata).
This leads to "filesystem not responding" [s]messages[/s] band-aids appearing well after they are useful, dolphin freezing if a system mount (e.g. NFS or a busy mechanical disk) is slow to respond or inaccessible, and all the other bug reports regarding poor performance and responsiveness problems with remote (i.e. high latency) filesystems.

The solution is quite obvious (though the implementation is probably not straightforward): Do not block the UI thread on filesystem operations, and provide some feedback as to why directory contents are slow to update (ideally with a timeout or manual way to cancel loading), again in a non-blocking manner so this information shows up when it's actually useful.

Windows 95 had far, far better handling of slow filesystems (remember that flashlight animation?), why we're still trying to come up with excuses and shove this fundamental design problem under the rug in 2024 I have no idea.

(In reply to Steve Vialle from comment #47)
> (In reply to SoftExpert from comment #46)
> > My 2 cents here: I believe the issue is outside Plasma entirely and purely
> > systemd related (more precisely systemd-fstab-generator related)
> 
> Same problems occur with openrc, so I really don't see how it has anything
> to do with systemd.
> 
> I see your 2c, and raise you my own:
> All of this has the same common cause, namely that Plasma can't handle slow
> system mounts (i.e. not KIO VFS) of any kind gracefully, because the  UI
> thread blocks on some filesystem call (likely a stat and/or something in
> solid collecting file metadata).
> This leads to "filesystem not responding" [s]messages[/s] band-aids
> appearing well after they are useful, dolphin freezing if a system mount
> (e.g. NFS or a busy mechanical disk) is slow to respond or inaccessible, and
> all the other bug reports regarding poor performance and responsiveness
> problems with remote (i.e. high latency) filesystems.
> 
> The solution is quite obvious (though the implementation is probably not
> straightforward): Do not block the UI thread on filesystem operations, and
> provide some feedback as to why directory contents are slow to update
> (ideally with a timeout or manual way to cancel loading), again in a
> non-blocking manner so this information shows up when it's actually useful.
> 
> Windows 95 had far, far better handling of slow filesystems (remember that
> flashlight animation?), why we're still trying to come up with excuses and
> shove this fundamental design problem under the rug in 2024 I have no idea.

I understand and share your frustration. I guess there are, indeed, 2 distinct problems combined and highlighted by this bug :
  1. the need for a better design of the KIO - UI interaction, making it truly asynchronous
  2. potentially, NFS could be made to behave - by carefully selecting more effective parameters.

When NFS is better configured, since it can approach in a different way the connection to network resources that are not yet available, KIO will have to wait very little time, so it appears in the UI like a fast operation; when NFS is badly configured or encounters a problem and, stubbornly, tries to handle the issue in synchronous mode, KIO will wait for the result to become available and will block the UI thread - and this is the part that can an should be addressed by this bug. 
Did I resume it correctly ?

Humm, the short victory did not persist; today I got the pseudo-freeze of the Plasma shell again; hopefully the fix for #323151 (due in 6.1) would address also this issue ?

(In reply to SoftExpert from comment #48)
>   1. the need for a better design of the KIO - UI interaction, making it
> truly asynchronous
Indeed. That, and the file manager and/or underlying frameworks _not_ attempting to access devices unrelated to the current view to begin with (which would address dolphins other persistent aggravation - it spins up and waits on all devices, even when the directory it's opening is not on those filesystems).

>   2. potentially, NFS could be made to behave - by carefully selecting more
> effective parameters.
>
> When NFS is better configured, since it can approach in a different way the
> connection to network resources that are not yet available, KIO will have to
> wait very little time, so it appears in the UI like a fast operation; when
> NFS is badly configured or encounters a problem and, stubbornly, tries to
> handle the issue in synchronous mode, KIO will wait for the result to become
> available and will block the UI thread - and this is the part that can an
> should be addressed by this bug. 

UI blocking bug, definitely. NFS "misbehaving"... Not so much. There is no badly configured NFS here, sync is the default for good reason and NFS blocks waiting for the server _by design_. 
Mounting NFS async will indeed reduce latency, but it will also cause it to lie to programs requesting sync writes and return before data is on stable storage, which can potentially cause data loss.

Network filesystems can and often are high latency. Mechanical disks can be high latency if they're in standby or otherwise occupied. KDE simply should not be making the assumption that the whole "local" (system mounts and all) filesystem tree is going to be fast enough that it can get away with blocking UI threads while waiting on I/O... 
Especially when that blocking freezes not only the file manager window displaying an affected directory, but also  _other_ dolphin instances, often along with parts of the desktop like the taskbar and notification system. 


If I attempt to enter the mountpoint of an unresponsive NFS export in a sane file manager (e.g. mc), that instance will likely freeze until the mount is available. That's not ideal, but it is expected and not a deal-breaker because it doesn't freeze my shell and I can continue using other instances of the file manager in other directories.
Dolphin on the other hand will freeze if I open it in an *unrelated* directory (likely trying to populate the "places" panel and other fluff), as will any other new or existing dolphin instances, because they share a common framework.
This is not reasonable behaviour by any stretch of the imagination, the primary job of a file manager is to operate on CWD, not crawl every possible mount on the system every time the user sneezes and go catatonic if it encounters anything that isn't on NVME.

To be fair none of this really belongs here though, this bug report is specifically for misbehaviour of a recent "improvement" meant to [s]direct blame at the underlying filesystem[/s] inform the user as to why their file manager is hanging... I.e. addressing a symptom rather than the cause. 
Then again none of the other multiple reports attributable to this seem to be getting any attention either, so whatever.

Well, I just got the fresh 6.1 version, and sure enough, the first thing after rebooting and logging in ... I got the freeze!
The whole Plasma shell is frozen for 90s -ish. 
The plasmoids that are showing small charts with temperatures, CPU usage, disk I/O, network traffic are frozen - and their dimensions are not yet adjusted; 50s or so during the freeze, there is an attempt to continue the layout adjusting (for example, one of the labels that is drawn outside its plasmoid area gets "sucked" inside) .
The Application launcher, the shell menus, everything (except the old and reliable Cairo Dock) is frozen. By the way, I can launch Konsole from the shortcut on the Cairo Dock - and the fresh terminal will behave normally (I can even consult one of the mounted NFS shares).
Once the 90s pass, the whole Plasma shell springs to life - the plasmoids finish their layout adjustments, charts start displaying data, launcher is available, etc, etc.

There was, somewhere, a redesign decision that now comes back with vengeance - and bites hard in the back side.

The thing is that (once the freeze has come to pass), if the NAS that is mapped at 3 different NFS mount points, becomes unavailable (for example it shuts down after midnight) the hell breaks loose: the slightest attempt to open Dolphin or try to open a file from a KDE application and bam! there is immediately the Ice Age - Dolphin or the app gets frozen and will wait at least 10-15 minutes before reacting a little bit and then freeze again.

I'm willing to collect logs and share them, but we need someone familiar with the inner workings to take a serious look at the root issue.

I removed the "filesystem not responding" notification