Bug 490247

Summary: Top Level Trash Not Working With Fuse Mounted Drive Pool
Product: [Applications] dolphin Reporter: jeffgt14 <jeffgt14>
Component: generalAssignee: Dolphin Bug Assignee <dolphin-bugs-null>
Status: REPORTED ---    
Severity: normal CC: dolphin-bugs-null, oliver.schramm97
Priority: NOR    
Version First Reported In: 24.05.2   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description jeffgt14 2024-07-13 21:58:35 UTC
***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
I have multiple EXT4 internal drives mounted at /mnt/data/ which are pooled together using mergerfs/fuse and mounted at /mnt/storage/. A few of these folders are then bind mounted to home directories such as /Music, /Videos.

Problem is, if I trash any file over the fuse mount (whether from /mnt/storage/Videos/file or /home/user/Videos/file) the file gets moved across drives to my local home drive at ~/.local/share/Trash. I can delete from /mnt/data/drive/Videos/file and it will correctly sent to the top level trash of that drive but obviously that defeats the point of the drive pool.

This issue seems to only occur in Dolphin. Any other file manager (Thunar, PCManFM, etc.) all correctly trash the file from the drive pool.

STEPS TO REPRODUCE
1. Mount fuse filesystem pooling multiple drives (mergerfs likely)
2. Trash file from /mnt/storage drivepool
3. 

OBSERVED RESULT
File is moved to /home/user/.local/share/Trash and unable to be restored from Trash

EXPECTED RESULT
File moved to top level trash on same drive at /mnt/data/drive. Restore moves file back to original location on drive

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Opensuse Tumbleweed
(available in About System)
KDE Plasma Version: 6.1.2
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
Not seeing any errors but there's definitely a huge delay (up to a minute) trying to trash any kind larger file (~1GB). Drivepool is not using any existing path create policies.

My mount settings from /etc/fstab:

/mnt/data/NAS-W6A159ZK:/mnt/data/WD-WCC4N1PCVASZ:/mnt/data/NAS-W6A14Z9A:/mnt/data/WD-VGH4160G /mnt/storage fuse.mergerfs noforget,inodecalc=path-hash,cache.files=off,dropcacheonclose=true,moveonenospc=true,minfreespace=20G,fsname=mergerfs,category.create=mfs,func.getattr=newest 0 0
Comment 1 Oliver Schramm 2025-12-15 12:41:56 UTC
Hey,
in the most recent versions of Dolphin and KDE Frameworks this might have been fixed, due to fixes to related issues with the trash, but I cannot test this on my side unfortunately.
Can you tell me, if this still happens with KDE Frameworks 6.21? It should be shortly available for openSUSE Tumbleweed (so you could wait a bit) or you can try the testing versions: https://software.opensuse.org/package/kf6-kio
Comment 2 jeffgt14 2025-12-29 01:51:43 UTC
(In reply to Oliver Schramm from comment #1)
> Hey,
> in the most recent versions of Dolphin and KDE Frameworks this might have
> been fixed, due to fixes to related issues with the trash, but I cannot test
> this on my side unfortunately.
> Can you tell me, if this still happens with KDE Frameworks 6.21? It should
> be shortly available for openSUSE Tumbleweed (so you could wait a bit) or
> you can try the testing versions:
> https://software.opensuse.org/package/kf6-kio

It appears the trash isn't found at all now and just asks to delete the file. Looks like KIO is just bypassing the trash located on the Mount point at /mnt/Storage/Trash-1000 and going straight to the root of the filesystem:

Kf.kio.workers.trash: No trash directory found for  "/" ! TrashImpl::findTrashDirectory returned -3
Comment 3 Bug Janitor Service 2026-01-13 03:47:20 UTC
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 4 jeffgt14 2026-01-13 05:04:05 UTC
It appears the trash isn't found at all now and just asks to delete the file. Looks like KIO is just bypassing the trash located on the Mount point at /mnt/Storage/Trash-1000 and going straight to the root of the filesystem:

Kf.kio.workers.trash: No trash directory found for  "/" ! TrashImpl::findTrashDirectory returned -3
Comment 5 Méven 2026-02-15 18:32:17 UTC
Git commit 5e98d7d0fe8a2b0c80ed450193ffcbd2c95378d6 by Méven Car, on behalf of Oliver Schramm.
Committed on 15/02/2026 at 13:20.
Pushed by meven into branch 'master'.

trashimpl: use mnt_id as trashId instead of dev_id

dev_id cannot account for btrfs subvolumes, so to finally fix
issues with them, we go the more sane route and stop looking
at devices but instead at mountpoints and their ids. This allows
us to remove Solid as a dependency from kio_trash, which will
additionally fix trashing on Plasma Vaults (though we have to
make an exception to exclude them from pseudofs like tmpfs).

Because mnt_id is actually an unsigned 64bit int, all functions
and variables with trashId had to be changed.
Related: bug 513350, bug 386104

M  +0    -1    src/kioworkers/trash/CMakeLists.txt
M  +8    -8    src/kioworkers/trash/kio_trash.cpp
M  +0    -1    src/kioworkers/trash/tests/CMakeLists.txt
M  +20   -5    src/kioworkers/trash/tests/testtrash.cpp
M  +3    -2    src/kioworkers/trash/tests/testtrash.h
M  +87   -126  src/kioworkers/trash/trashimpl.cpp
M  +25   -35   src/kioworkers/trash/trashimpl.h

https://invent.kde.org/frameworks/kio/-/commit/5e98d7d0fe8a2b0c80ed450193ffcbd2c95378d6