Bug 479262

Summary: [Btrfs/ostree] Directory exists but didn't pass the security checks, can't use it
Product: [Frameworks and Libraries] frameworks-kio Reporter: Henning <boredsquirrel>
Component: TrashAssignee: KIO Bugs <kio-bugs-null>
Status: REPORTED ---    
Severity: major CC: kdelibs-bugs-null, nate, travier, voidpointertonull+bugskdeorg
Priority: NOR    
Version First Reported In: 5.247.0   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Henning 2024-01-01 16:13:46 UTC 
kf.kio.workers.trash: Root trash dir "/\u0000/.Trash" exists but didn't pass the security checks, can't use it
kf.kio.workers.trash: Directory "/\u0000/.Trash-1000" exists but didn't pass the security checks, can't use it
kf.kio.workers.trash: Root trash dir "/\u0000/.Trash" exists but didn't pass the security checks, can't use it
kf.kio.workers.trash: Directory "/\u0000/.Trash-1000" exists but didn't pass the security checks, can't use it

Specified App:
kf5-kio-ntlm-5.113.0-1.fc40.x86_64
kf5-kio-core-libs-5.113.0-1.fc40.x86_64
kf5-kio-doc-5.113.0-1.fc40.noarch
kf5-kio-gui-5.113.0-1.fc40.x86_64
kf5-kio-file-widgets-5.113.0-1.fc40.x86_64
kio-extras-kf5-24.01.85-1.fc40.x86_64
kf5-kio-widgets-libs-5.113.0-1.fc40.x86_64
kf5-kio-core-5.113.0-1.fc40.x86_64
kf5-kio-widgets-5.113.0-1.fc40.x86_64
kio-fuse-5.1.0-1.fc40.x86_64
kf6-kio-core-libs-5.247.0-1.fc40.x86_64
kf6-kio-doc-5.247.0-1.fc40.noarch
kf6-kio-gui-5.247.0-1.fc40.x86_64
kf6-kio-file-widgets-5.247.0-1.fc40.x86_64
kio-extras-24.01.85-1.fc40.x86_64
kf6-kio-core-5.247.0-1.fc40.x86_64
kio-admin-23.08.2-1.fc40.x86_64

--- Software ---
OS: Fedora Linux Rawhide.20231229.n.0 (Kinoite Prerelease)
KDE Plasma: 5.91.0
KDE Frameworks: 5.113.0
Qt: 5.15.11
Kernel: 6.7.0-0.rc7.20231228gitf5837722ffec.57.fc40.x86_64
Compositor: wayland
Comment 1 Pedro V 2024-01-02 11:56:21 UTC 
Those paths don't exactly look healthy, there's a need for quite a bit more context here:
- What's the full path of the file you attempted to trash?
- What's the mount point that file resides on?
- Is your $HOME on a different mount point?

If I interpret the problem well, then those extra zero bytes will lead to the path being just "/" which of course really shouldn't be used for trash purposes, but where are the garbage bytes coming from? Is KMountPoint::currentMountPoints getting an unexpected null byte somewhere and is Qt turning that into 2 bytes of zero due to using the horrible UTF-16 mess?
Alternatively it could come from Solid::Device::listFromQuery, but that's in case of scanning for trash directories, and without more info I'll assume that the error was encountered when attempting to use the trash.
Comment 2 Henning 2024-01-02 12:38:26 UTC 
Using an OSTree filesystem, so all files are mounted in /var/home. The system uses BTRFS

nvme0n1p3                                   259:3    0 929,9G  0 part  
  └─luks-abcd-xyz1-2345  253:0    0 929,9G  0 crypt /var/home
                                                                         /var
                                                                         /sysroot/ostree/deploy/fedora/var
                                                                         /usr
                                                                         /etc
                                                                         /
                                                                         /sysroot

I didnt delete any file actively I think, but if then it was somewhere in /var/home
Comment 3 Henning 2024-03-09 00:40:06 UTC 
some ideas, flatpak? or maybe distrobox with podman?