I'm seeing this too with homes on separate btrfs subvolumes. Seems to be caused by: https://invent.kde.org/frameworks/kio/-/commit/0a63a9190642f9b7b8fd6252afffbf48f1a36165

This change makes sense with tmpfs filesystems but is very annoying with persistent filesystems now.

Same problem!  (plasma 6.5.4,  KDE frameworks 6.21), .Trash-1000 existing!
I do have subvolumes like /clouds /data and I do NOT want them in my $HOME folder

Trash works now by manually making a .Trash-1000 directory in the /hdd root and setting permissions for it, though this still feels like a regression.

I'm having the same problem with my Arch Linux system; it was working perfectly fine a few days ago.

I'm mounting a subvolume of the Btrfs partition on my second hard drive to ~/downloads/xxx, and deleting files from it results in an message.

(In reply to ironplasma from comment #3)
> Trash works now by manually making a .Trash-1000 directory in the /hdd root
> and setting permissions for it, though this still feels like a regression.

Can't confirm this. I've created a Trash-dircetory with the uid of my user in / but still get: "kf.kio.workers.trash: No trash directory found for  "/" ! TrashImpl::findTrashDirectory returned -2"

Interestingly, the 'files' and 'info' directories got created within the Trash-dir.

For info, I'm observing this behavior with Gentoo

Hey, thank you all for the report!

While the old behavior was to just silently copy the files across partitions to your home partition, the "fix" of course should not be to just disable trashing at all for many setups.
So, in reality, the fix has probably made this issue with trash+btrfs volumes more apparent: https://bugs.kde.org/show_bug.cgi?id=395023
We should have fixed this in one go so we don’t have this visual regression, I am sorry!

> Can't confirm this. I've created a Trash-dircetory with the uid of my user in / but still get: "kf.kio.workers.trash: No trash directory found for  "/" ! TrashImpl::findTrashDirectory returned -2"
Thank you very much, this message does help a lot on triaging this!

In short: if somebody here does have this issue with a non-btrfs volume, please mention it! So far it appears to me as all of you have this issue with btrfs-volumes, so this is part of the #395023 issue.

> In short: if somebody here does have this issue with a non-btrfs volume,
> please mention it! So far it appears to me as all of you have this issue
> with btrfs-volumes, so this is part of the #395023 issue.

The mount on /hdd is a btrfs partition, yes, but unlike in the case of the others it isn't a subvolume, if that makes any difference in this case.

(In reply to ironplasma from comment #3)
> Trash works now by manually making a .Trash-1000 directory in the /hdd root
> and setting permissions for it, though this still feels like a regression.

Does your user have write permission for the /hdd root? If yes, can you please execute:
solid-hardware6 query StorageAccess.accessible==true
and tell me if your device appears in the output?

> Does your user have write permission for the /hdd root? 
It does not, only to a folder within it. Still ran your command just in case its still useful and the device does appear in the output.

Can confirm on KDE Linux where /home is a Btrfs subvolume; items located anywhere else can't sent to the trash.

I wonder how GNOME handles btrfs volumes. It must run into similar problems..

Creating a folder named .Trash on the drive root with 1777 permissions (sticky bit set) should fix the issue, though?
I'll try to investigate around Christmas :)

Thanks a lot!

>In short: if somebody here does have this issue with a non-btrfs volume, please mention it! So far it appears to me as all of you have this issue with btrfs-volumes, so this is part of the #395023 issue.
Hi oliver i experience a similar problem but my whole system is ext4
on kSystemLog i see 
>No trash directory found for "/" ! TrashImpl::findTrashDirectory returned -3 warning
coming from kioworker whenever i try to delete something outside home
ive asked people on discuss to share their FS'es as well
https://discuss.kde.org/t/kioworker-no-trash-directory-found-for-trashimpl-findtrashdirectory-returned-3-on-secondary-drives/42597

(In reply to Oliver Schramm from comment #12)
> I wonder how GNOME handles btrfs volumes. It must run into similar problems..
> 
> Creating a folder named .Trash on the drive root with 1777 permissions
> (sticky bit set) should fix the issue, though?
> I'll try to investigate around Christmas :)

It does not.

I was able to make it work by binding the trash folder to my Home's trash folder

>sudo mount --bind /home/$USER/.local/share/Trash /$FOLDER/.Trash-1000

But that is not an acceptable fix as you need to do it manually for every subvol and every new one you create in the future.

In conclusion I am not sure I understand who will fix this?
Will plasma fix this or do users need to find a workaround?

If a .Trash folder exists, it should be used. I'll have to figure out, why some users come across this problem and others don't. So this has to be fixed.
Otherwise, if the user doesn't have write permissions in the drive root and there is no .Trash folder, we'll have to see how we can work around this.

Thank you all for the reports so far!

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/2089

I think I'm also seeing this, my setup is a little different so I'll mention it in case it's an edge case:

/home is a btrfs volume
/home/$USER/.local/Trash was the original location of the trash in my home directory
/home/$USER/Documents/$SUBVOL is a btrfs subvolume
/home/$USER/Documents/$SUBVOL/Trash is a subdir in the subvol, which is the actual trash folder now
/home/$USER/.local/Trash has been replaced with a symlink to the above (so it appears the trash is in the usual place)

Files inside the subvol cannot be trashed, files outside the subvol can, including those which are inside the home directory. This is a bit reversed from some of the above reports but it seems related, hope I'm not hijacking.