Bug 505852

It seems it's due to the new feature of checking disks for errors by default. For me it either outright fails or has an error message like 

An error occurred while accessing 'LinuxDisk', the system responded: An unspecified error has occurred: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

After trying twice, it ultimately succeeds, despite the errors.

Can you collect the logs please, because I don't have any disks. 
1. In terminal execute: QT_LOGGING_RULES="org.kde.applets.devicenotifier=true" plasmawindowed org.kde.plasma.devicenotifier &> log.txt
2. Reproduce the bug
3. stop the process in terminal
4. attach the file log.txt here

Created attachment 182481 [details]
Logs of devicenotifier.

Add logs.

Looks like this is expected behavior. Before mounting it checks the device for errors. The slowness of checking is proportional to the disk size and read speed. You have a 2Tb drive so that why it is so slow. The solution here would be to make the check operation optional.

(In reply to Bogdan Onofriuchuk from comment #4)
> Looks like this is expected behavior. Before mounting it checks the device
> for errors. The slowness of checking is proportional to the disk size and
> read speed. You have a 2Tb drive so that why it is so slow. The solution
> here would be to make the check operation optional.

Thanks. 

Hope it can be an optional choice.

(In reply to Sigmund from comment #5)
> (In reply to Bogdan Onofriuchuk from comment #4)
> > Looks like this is expected behavior. Before mounting it checks the device
> > for errors. The slowness of checking is proportional to the disk size and
> > read speed. You have a 2Tb drive so that why it is so slow. The solution
> > here would be to make the check operation optional.
> 
> Thanks. 
> 
> Hope it can be an optional choice.

Is it possible to disable the this check? 

But how

A workaround is suggested. 
Open System settings -- > Connected devices --> Disks & Cameras --> Device actions", add new action by the button "Add", give it any non-existing name and then enter the data as shown in the screenshot attached.
Use new action instead of "Mount" to mount the removable disk.

Created attachment 182549 [details]
workaround

Sorry, no screenshot is attached in my previous comment
A workaround is suggested. 
Open System settings -- > Connected devices --> Disks & Cameras --> Device actions", add new action by the button "Add", give it any non-existing name and then enter the data as shown in the screenshot attached.
Use new action instead of "Mount" to mount the removable disk.

Hi ! Same issue since the 6.4 upgrade, with an USB harddrive with ext 4 partitions. 
Actually, I have waited several minutes to no avail and had to reboot :-/

Is it really the expected behaviour ?

For some reason, the check does not occur when mounting the partition through Dolphin. (pfew !)

BTW, may I suggest the bug report name is changed accordingly, to something like :

"Mounting a removable hadrrive (BTFS / EXT4) systematically forces a very long scan, leading to a timeout".

I really wonder if that is the expected behaviour...

I can confirm this behavior. Mounting a fully loaded 4TB external hard drive now takes four minutes, during that time I can hear the drive activity. After about a minute, I get a message saying I'm not authorized to mount the device. After the four minutes, I see in the log that the device has been mounted. This is new since version 6.4; before, mounting the device was done instantly, and when I mount the device on the console as root, it's done immediately.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5624

Happens here too, with an almost full, 2 TB BTRFS hard disk. The extreme slowness is new. The btrfsck check takes 20 minutes. Mounting was somewhat slow earlier too (maybe half a minute); Idk if it's the plasma shell's behavior that changed, or perhaps the default operation of btrfsck became much slower, or perhaps Solid via udisks now reports that it can check the drive, while previously it couldn't.

Also note that btrfsck doesn't even repair anything by default, its repair functionality is considered unsafe, while AFAIK btrfs automatically repairs errors that can be safely repaired when mounting, so btrfsck should be unnecessary.

Perhaps a reasonable behavior would be to try mounting first, and only fsck (with no timeout) if mounting fails with an error that indicates that the file system is damaged, and then try to mount again. Even then, ideally only run fsck if the file system has an fsck tool that can safely repair some kinds of errors, otherwise just report that the file system is damaged (Idk if there's a way to get this information from udisks).

Git commit a30f314d9fe646080f314f2070489ec897467c43 by Bohdan Onofriichuk.
Committed on 14/07/2025 at 18:14.
Pushed by littlesweet into branch 'master'.

applets/devicenotifier: don't do check in mount action

Don't do check in the mount action. Create another action for check. Also
change the name of the mount action to just "mount" if check was done.

M  +1    -0    applets/devicenotifier/CMakeLists.txt
A  +82   -0    applets/devicenotifier/actions/checkaction.cpp     [License: GPL(v2.0+)]
C  +5    -9    applets/devicenotifier/actions/checkaction.h [from: applets/devicenotifier/actions/mountaction.h - 059% similarity]
M  +8    -19   applets/devicenotifier/actions/mountaction.cpp
M  +0    -1    applets/devicenotifier/actions/mountaction.h
M  +10   -1    applets/devicenotifier/actionscontrol.cpp
M  +5    -2    applets/devicenotifier/devicemessagemonitor_p.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/a30f314d9fe646080f314f2070489ec897467c43

(In reply to Martin Schnitkemper from comment #11)
> I can confirm this behavior. Mounting a fully loaded 4TB external hard drive
> now takes four minutes, during that time I can hear the drive activity.
> After about a minute, I get a message saying I'm not authorized to mount the
> device. After the four minutes, I see in the log that the device has been
> mounted. This is new since version 6.4; before, mounting the device was done
> instantly, and when I mount the device on the console as root, it's done
> immediately.

Same here, but with a 4 TB drive on USB 2 it takes up to two hours.

Has the default action "Mount and Open" changed lately to "*Always* do a check first 
and mount after" behavior?  

Does it ignore a 'clean' flag in partitions super block (if something like this exists)?

more observations: https://discuss.kde.org/t/mounting-external-usb-disks-now-checks-before-mounting/37439/2

(In reply to Mahendra Tallur from comment #9)
 
> For some reason, the check does not occur when mounting the partition
> through Dolphin. (pfew !)

Can confirm this. It is only the Widget,  that checks before mounting.  Dolphin mounts immediately without any complaints, a clean unmounted disk, whereas the default action triggers checking.  I miss seeing the point in doing so, when the drive is clean - without errors.

I am on KDE Plasma 6.5.0 and I am still experiencing this issue, even though https://invent.kde.org/plasma/plasma-workspace/-/commit/a30f314d9fe646080f314f2070489ec897467c43 is supposedly included in Plasma 6.5.0. I clicked "Mount and Open", the default action presented by the systray applet, and `btrfsck` is running for about an hour now and the filesystem still is not mounted in Dolphin.

Operating System: NixOS 25.11
KDE Plasma Version: 6.5.0
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.4 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics
Memory: 32 GiB of RAM (30,6 GiB usable)
Graphics Processor 1: AMD Radeon 680M
Graphics Processor 2: AMD Radeon RX 6800S
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ROG Zephyrus G14 GA402RK_GA402RK
System Version: 1.0

(In reply to Dennis Schridde from comment #17)
> I clicked "Mount and Open"
Click "Mount without verifying" instead.

Hi,
could you please reconsider the final solution? Having default option "Mount and Open" which automatically triggers the check is not very intuitive, as someone who does not know about this can be surprised not to be able to do anything for long minutes or even tens of minutes for larger (and slower) external disks, and if you need to just "quickly copy something and leave" and by mistake click default action, it is very annoying.
Not to mention there is missing "mount and open without scanning" so you are not able to mount and open and skip check with just single click (you need to open submenu, mount without check and then open), which is also a bit awkward.
Or at least please allow us to disable the automatic check in settings :-)

Not sure you should have unilaterally reopened the ticket. Are you generally allowed to?

(In reply to Roke Julian Lockhart Beedell from comment #20)
> Not sure you should have unilaterally reopened the ticket. Are you generally
> allowed to?

Well, yes i've tried to reopen, as i did not know whether additional comment on closed issue will get any attention, and imho in terms of original problem it is not really fixed for the reasons i've posted. If i did something wrong, i do apologize (though i'd guess i'd not have permissions, if regular user should not be allowed to reopen?)

(In reply to Petr Bartos from comment #21)
> (In reply to Roke Julian Lockhart Beedell from comment #20)
> > Not sure you should have unilaterally reopened the ticket. Are you generally
> > allowed to?

Yes, people are allowed to reopen bugs for a variety of reasons. If it wasn't allowed, the option wouldn't be in Bugzilla.

> Well, yes i've tried to reopen, as i did not know whether additional comment
> on closed issue will get any attention

All of the people subscribed to a bug will get emails from it, regardless of the open / close state.

. and imho in terms of original
> problem it is not really fixed for the reasons i've posted. If i did
> something wrong, i do apologize 

From what I understand, the fix that was merged was to separate the mount and check actions in 
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5624

I see what you're saying about the UI not allowing the user to easily and intuitively mount a disk without running the verification check. I understand that from the user's point of view, the original problem is still a problem.

Is there even a filesystem in common use today where there's any benefit to checking before attempting to mount? In my experience, a filesystem is either clean and it's fine to just mount it; or it was unmounted uncleanly but it will be automatically fixed on mount; or mount will fail but won't damage the filesystem further, and *then* you run fsck. Even then, it depends on the filesystem whether a batch-mode fsck will actually repair anything; with btrfs, it won't. Am I wrong about any of this (in particular, that attempting to mount an unclean filesystem generally won't damage it further)?

(In reply to Grósz Dániel from comment #23)
> in my experience, a filesystem is
> either clean and it's fine to just mount it; or it was unmounted uncleanly

this! 

what is the benefit of a forced fs check on a clean filesystem? or what i'm missing?

Hi ! I may be mistaken, but it seems the fix is applied differently depending on the distribution :

- on my KDE Neon, the default action is still to verify & mount
- on my Manjaro KDE (Arch based), since the fix has been applied, the default action is to mount without checking

Indeed, I cannot expect the "regular" users to manually select "mount without checking". If not, it triggers a several minutes check with a big external hard drive.

Thanks a lot, everyone <3
Cheers !

(In reply to Mahendra Tallur from comment #25)
> Hi ! I may be mistaken, but it seems the fix is applied differently
> depending on the distribution :
> 
> - on my KDE Neon, the default action is still to verify & mount
> - on my Manjaro KDE (Arch based), since the fix has been applied, the
> default action is to mount without checking
> 
> Indeed, I cannot expect the "regular" users to manually select "mount
> without checking". If not, it triggers a several minutes check with a big
> external hard drive.
> 
> Thanks a lot, everyone <3
> Cheers !

I am on Fedora 42 with Plasma 6.5.2. I definitely see the new menu options from the merge request. Not sure if the default action is defined somewhere else (which is not yet updated), but even in the videos and comments in the merge request it seems that the default action is still expected to do the check and there was only added additional option to skip it.