SUMMARY When mounting a device that takes a long time mounting (in my case a BTRFS filesystem on LUKS encryption residing on a slow external USB HDD, takes more than 20 seconds to mount), the KDE Plasma disks applets spits an error “Not authorized to mount filesystem”, even though the mount ultimately succeeds. STEPS TO REPRODUCE 1. Connect an external USB device containing a FS that is really long to mount (i.e. a slow USB device containing a BTRFS filesystem on top of LUKS encryption) 2. The disk applet pops-up 3. Click on “mount“ or “mount and open” OBSERVED RESULT - After some time the disks applet spits an error message stating that the user is not authorized to mount the device - Nevetheless, the mount eventually succeeds - But the disks applet will never be aware that the mount ultimately succeeded, thus will never propose an option to unmount/disconnect the device EXPECTED RESULT - I would expect the disk applet to wait for the device to actually mount, and not assume a somewhat long mount time is an error. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro Linux KDE Plasma Version: Plasma 5.26.3 ADDITIONAL INFORMATION - Same device works good with automounters in Gnome or Cinnamon, only KDE causes an issue.
Created attachment 183406 [details] output of "sudo dmesg --follow -T"
Created attachment 183407 [details] output of "udisksctl monitor"
This bug continues to exist even in a fully updated Arch/KDE platform: after connecting an external hard drive to the USB port, when I click “Mount & Open” in the KDE Disks & Devices notifier window, it says “You are not authorized to mount this device”. Eventually, the device does mount – with the “Safely remove” button appearing in the KDE notifier window as well as the (contradictory) “you are not authorized” warning. I posted a workaround here: https://www.reddit.com/r/SteamDeck/comments/167c8c8/you_are_not_authorized_to_mount_this_device/ I also submitted a udisks2 issue to https://github.com/storaged-project/udisks/issues/1393 , but discussion there suggested that this is likely a KDE issue and thus led to this comment. Here, as additional attached information, I’m providing the outputs of “sudo dmesg --follow -T” and “udisksctl monitor” – as you can see, it took almost 6 minutes for the device to mount. I suspect many folks don’t wait that long and assume that the device won’t mount at all.
chiming in to report that I'm also affected by this. symptoms match and work-around works so I'll skip logs, but I have a few circumstantial observations. I run karaoke shows from a laptop. it was on Garuda(/Arch+KDE) Linux until earlier this week, and hadn't been updated in several months as it wasn't being used for anything else. I'd moved to CachyOS(/Arch+KDE) on my desktop, and this week decided to switch the laptop over too. at that point, the 2TB Western Digital drive holding my karaoke library would no longer mount through KDE, displaying the "not authorized" error as described here. I brought it to my desktop, and it wouldn't mount there either. however, a 128GB flash drive mounts fine on either. both drives are exfat; `fsck.exfat` reports no errors. when I found `sudo mount` in a terminal worked, I ran with that as a quick fix. two possibly helpful insights from this: - my immediate suspicion (before finding sfdriver's udisks2 bug thread) was a timeout issue, because the karaoke collection I'm using has almost 200k files in a single folder and that's something FAT is historically terrible with. it works well enough when directly accessing individual files, but full directory listings can be VERY slow. so if e.g. Dolphin is trying to pre-cache an index of drive contents before telling the user the drive is mounted, that could easily exceed a naive timeout. - I can't say exactly when the last proper update was on my laptop before this week, but the absolute maximum is six months. while the original bug report here is two years old, whatever change has caused it to crop up again is almost certainly new in 2025.
So in Plasma 6.5, we added a "Mount without verifying" option. That works if you already know about the issue with long verification times and potential timeouts with huge disks. However it doesn't solve the issue for the common case, i.e. plug in and click "Mount and open" I think we could benefit from a way to let the user cancel the verifying if they feel like it's taking too long. And also, we should find a way to make it not time out like this.