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.

Seeing the same error with a btrfs partition on an HDD with bind mounts for certain directories under /home. Only those directories are affected.

plasmashell 6.5.4

Sorry, I don't know how to edit comments and I had an error in my report. 
It's an EXT4 partition on an HDD with bind mounts for directories in my /home subvolume, btrfs on SSD.

Seeing the same issue on both arch linux and fedora 43. This also affects plasma-vaults.

(In reply to Frank from comment #15)
> (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?

experiencing the same thing.. but oddly not all my subvols are affected.  I tried the bind and it worked.  A work around but definately not a fix.

For some reason the bind mount workaround doesn't work for me, but I was able to achieve it via using a symlink to the actual subvolume folder within the `subvol=/` top level mount for the btrfs partition

(In reply to Oliver Schramm from comment #7)
Hi, I'm using ext4 on Manjaro and getting this error when I try to delete from my encrypted folder that uses gocryptfs. .Trash-1000 was already created for this mounted folder but was only used by some applications when I deleted files through them, and never by Dolphin. Deleting and creating a new .Trash-1000 folder does not fix the issue, but does get populated by /info and /files. Personally, I preferred when deleting files always went to the /home/$USER/.local/share/Trash folder, because I didn't have to wonder why space wasn't being freed up when I deleted things and emptied the main trash in my .local dir. But that's just me, Thanks for looking into this.

Ah, that's a good note. For me on btrfs, when I try to delete something it also successfully creates the.Trash-1000 directory, and the info and files inside of it. And then it errors and says it can't delete. So it's clearly figuring out what location to use

I use Btrfs subvolumes nested inside @home to allow for independent snapshots and rollbacks. This worked as expected until recently, now, attempting to trash files from these subvolumes triggers a dialog forcing permanent deletion.
The ".Trash-1000 in each subvolume with the correct permissions" workaround should be temporary, not a final fix.

I have only 2 partitions. HOME and /. Both ext4. I was able to trash any file on the / as long as the user had the right permissions.

Now I can only trash file in the HOME partition for every other file dolphin says "The trash is not available for this item’s location. Permanently delete it instead?"

strace -f -o /tmp/dolphin.strace dolphin

QGridLayout: Multi-cell fromRow greater than toRow
kf.baloo: Failed to add exclude folder config entry for "/koko/kicad/"
kf.coreaddons: "Could not load plugin from /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: Cannot load library /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: libappimage.so.1.0: cannot open shared object file: No such file or directory"
kf.coreaddons: "Could not load plugin from /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: Cannot load library /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: libappimage.so.1.0: cannot open shared object file: No such file or directory"
kf.coreaddons: "Could not load plugin from /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: Cannot load library /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: libappimage.so.1.0: cannot open shared object file: No such file or directory"
kf.coreaddons: "Could not load plugin from /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: Cannot load library /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: libappimage.so.1.0: cannot open shared object file: No such file or directory"
kf.coreaddons: "Could not load plugin from /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: Cannot load library /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: libappimage.so.1.0: cannot open shared object file: No such file or directory"
kf.kio.filewidgets.kfilewidgets: Your 'templates' folder is set to your home folder. This is probably an error in your settings. Ignoring it. You can change the setting by running `systemsettings kcm_desktoppaths`. 
kf.coreaddons: "Could not load plugin from /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: Cannot load library /usr/lib/qt6/plugins/kf6/thumbcreator/appimagethumbnail.so: libappimage.so.1.0: cannot open shared object file: No such file or directory"

kf.kio.workers.trash: No trash directory found for  "/" ! TrashImpl::findTrashDirectory returned -3

I have the same problem with ZFS datasets mounted into the home directory, basically most of the folders in my home directory are separate mounts.

Take this example from the output of mount:
zalpollo/nosnap/nextcloud/dokumente on /home/numerfolt/Persönliche Dokumente type zfs (rw,relatime,xattr,posixacl,casesensitive)

When trying to delete a file from "Persönliche Dokumente" the dolphin log reports
"kf.kio.workers.trash: No trash directory found for  "/" ! TrashImpl::findTrashDirectory returned -3"

Persönliche Dokumente/.Trash-1000 does exist.
When I remove the .Trash-1000 folder, it gets recreated when trying to delete a file, but the error persists.

Creating a .Trash-1000 folder with correct permissions in / changes the error to
"kf.kio.workers.trash: No trash directory found for  "/" ! TrashImpl::findTrashDirectory returned -2"

*** Bug 515045 has been marked as a duplicate of this bug. ***

Also affected by the issue. Like others I'm using btrfs with subvolumes. .Trash-$ID Folders exist but it's still not working. Issue started mid december, I sadly can't recall which version got installed at this stage. Currently it's 6.22 and the error still persist.