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.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/2044
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