Bug 506755

Summary: Unexpected Trash behavior on NFS with all_squash and Mismatched UIDs
Product: [Frameworks and Libraries] frameworks-kio Reporter: Oliver Schramm <oliver.schramm97>
Component: TrashAssignee: KIO Bugs <kio-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: kdelibs-bugs-null
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: https://invent.kde.org/frameworks/kio/-/commit/8a0d9b64849115dd40ac20b3f20d9ff645a32e71 Version Fixed/Implemented In: 6.20
Sentry Crash Report:

Description Oliver Schramm 2025-07-08 11:58:06 UTC 
SUMMARY
When moving files to trash on an NFS export, the experience differs from the first time you do it, if the remote user and local user do not match. Because then it will be downloaded to local trash, which can take a lot of time. 

STEPS TO REPRODUCE
1. Mount an NFS export with all_squash and anonuid and anongid not equal to your local one.
2. Make sure that the user has full write access to the remote folder. And make sure, no trash infrastructure exists already.
3. Now move one file to trash.
4. And then move another file to trash.

OBSERVED RESULT
After moving the first file to trash, the trash infrastructure is created with ".Trash-$LOCALUID" and 700 permission, owned by the remote user (say, 102). Because we act as the remote user, it will be writable to us. The first file will be in fact moved to that newly created infrastructure. This is fast.
After moving the second file to trash, it’s downloaded and placed in the local trash infrastructure (~/.local/share/Trash), taking a lot of time (if the file is big).

EXPECTED RESULT
Moving to trash will be instantaneous and solely happening on the remote NFS export for both files.

ADDITIONAL INFORMATION
This happens, because if the .Trash-$UID folder exists, it is checked that it is owned by the user and writable – with the local user ID: https://invent.kde.org/frameworks/kio/-/blob/b16d4a249b00a8be187f12c150daff42107b15bf/src/kioworkers/trash/trashimpl.cpp#L1155
But if the folder doesn't exist, it will be created if possible and used without further checks: https://invent.kde.org/frameworks/kio/-/blob/b16d4a249b00a8be187f12c150daff42107b15bf/src/kioworkers/trash/trashimpl.cpp#L1170

Not sure how to fix it, or if my setup is just weird? I almost don't think so. The current workaround is, to have a .Trash-$UID folder owned by a remote user with the same UID as my local one and have it world-writable with 777, so that it can be written by the remote user I am acting as. This does feel very hacky, which is why I am bringing this behavior up.
Comment 1 Bug Janitor Service 2025-11-03 16:21:53 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/2044
Comment 2 Oliver Schramm 2025-11-04 21:55:03 UTC 
Git commit 8a0d9b64849115dd40ac20b3f20d9ff645a32e71 by Oliver Schramm.
Committed on 04/11/2025 at 20:20.
Pushed by meven into branch 'master'.

trashimpl: better determine trashForMountPoint for network file systems

With uid mapping the local userid and remote userid might not match;
if permissions are checked by ownership, KIO won't consider a trash
directory even if it is writable.
This forced a fallback to the home trash which could mean moving a file
over a network, which is catastrophic for huge file sizes.

To fix this, instead of checking ownership and mode bits, use access()
which correctly queries the VFS for permission.

Signed-off-by: Oliver Schramm <oliver.schramm97@gmail.com>

M  +8    -8    src/kioworkers/trash/trashimpl.cpp

https://invent.kde.org/frameworks/kio/-/commit/8a0d9b64849115dd40ac20b3f20d9ff645a32e71