I began noticing recently that sometimes when trying to send a file to the trash, I was told that it couldn’t be moved there and that I’d have to delete it entirely to get rid of it. I didn’t really think anything of this at first, until I began to suspect that it was only happening with files in my /home directory.
My /home directory is on its own partition on a standard hard disk. The rest of the file system is on another partition on an SSD. In order to fully reap the speed benefits of an SSD, I symbolically linked as many non-personal directories as I could from /home to /var/jay on the SSD. These included ~/.local, ~/.cache, ~/.gconf, ~/.mozilla, etc.
I didn’t really know much about the way Linux/GNOME handles Trash. Files deleted from a third internal hard disk or from USB sticks would be moved to /.Trash-1000 on that device, while appearing in “Trash” in Nautilus. Files from a user’s home directory, however, don’t go to /home/.Trash-1000, or even /.Trash-1000 — instead, they go to ~/.local/share/Trash. Because in my setup this directory was on the SSD rather than the hard disk with the /home partition, GNOME refused to move it there, since that would require copying from one disk to another, which GNOME’s developers (smartly, I think) believe would be alarmingly time-consuming for someone who’s just trying to delete some files — they shouldn’t expect to see a copy dialog grinding away.
In order to try to fix this, I made ~/.local/share/Trash into a symbolic link itself, back to the /home partition at ~/Trash. After this change, things were getting trashed properly — at least, I wasn’t asked to delete them entirely — but they weren’t showing up in Nautilus’s Trash view. I don’t know how Nautilus makes itself aware of all the trash folders spread across different devices, but for whatever reason it wasn’t picking up on this one, even after several reboot cycles.
Finally I gave up and moved ~/.local back onto the same partition as /home, and now everything’s back to normal. But I’d still like to know if it’s possible to keep ~/.local on a separate disk while retaining GNOME’s and Nautilus’s ordinary trash behavior.
Richard Ayotte says:
I just ran into the same problem. Thanks for posting. I’m looking for a solution.
trash man says:
Apparently the trash unix/linux-desktop specifications don’t really allow for trash to work across different partitions. It even tries to actively prevent it by checking whether the trash folder is a symlink or something.
Some implementations do follow that completely (trash-cli), while others don’t and can be “cheated” (KDE GUIs on latest KDEs/QT4/QT5, I think), while others will apparently just delete the file without moving it to trash (the CLI command kdetrash, funnily enough).
That I don’t understand. While It’s completely reasonable that it wouldn’t do that by default, as it would just make everything needlessly slower, I think ideally it should allow for “hacking” the system with symlinks. I think I may have read of someone having hacked this with a bind-mount, though, even though I don’t even understand how would that be from this basic description.
Ken Jensen says:
On USB-disks we get a trash-folder during creation, named something like .trash-1000 (.trash-GID) the group Id. Where all files and folders deleted (without shift) ends up, and is automatically linked to the Trash Icon in filers or desktop, so there must be a similar neat solution somewhere out there!!
Ken Jensen says:
I’ve had the same problem in Xubuntu, and then I made it worse!! (I’m sharing the big folders from home (Video,Mucic,Documents,Pictures…) with a Suse gecko!
Alas the problem lies with the file ownership and rights! It seems that on Unix compliant drives, all the rights to the files and folders belong to root. Root created the .Trash-Xxxx when we evoked a Trash operation. So we need to chown it to our-self and our main group (that normally is our name too (except in Suse and the like where it is users!). Now we need to set the rights, all folder-operations are ruled by the guid not the uuid so we need to append those rights, so go into the folder containing the .Trash-uuid, and run:
chmod g+wx -R .Trash-1000
g+wx sets the write and execute rights for your group. -R do it recursively Beware your uuid could be different so change it to match yours. Now set the execute bit for your user, sometime (mostly) they are missing!
chmod u+x -R .Trash-1000
Now you need to log out and back in (or reboot) to introduce the changes to the OS.
Now it should work, but there will be a lot of cleaning up (after our-self). Most of the trash folders in the shared folders can be removed (BUT wait a week so you are positive they are no longer in use!
So Symbolic links works with Trash, bind-links do not!
I had to use the T flag when creating the symlinks:
ln -sT /mnt/(Disk/Partition)/Pictures/ /home/UUID/Pictures
All of this is elsewhere on this site, I just found these helpfull bits!