I'm trying to set up shared home directory for two Linux installations and thus I'm using bind-mounts. My user is named dbz and his home directory is /home/dbz. I also have shared directory /home/shared where I store my shared files (this folder is also owned by user dbz).

I mount another directories from this shared directory into my home directory using binding:

mount -B /home/shared/work /home/dbz/work

This solution solves my needs and the only issue I have and don't know how to resolve is - when I'm trying to delete a file or directory from mounted directory I cannot delete it to trash, only permanent deletion is possible. For example:

  • deleting file /home/shared/work/test.txt: OK, because deleting right from the directory where the file test.txt resides;
  • deleting file /home/dbz/work/test.txt: CAN'T, because... by the way, because what? do bind-mounts have some restrictions on file deletion?

Finally an issue submitted to bugzilla.kernel.org

  • Is /home/shared and /home/dbz on the same filesystem? (i.e. /home is a mount point) What you are describing is a cross device link; mv works by creating a link and removing the original. When the src and dst are in different mounts, this cannot happen. (the bind should be transparent to the process.)
    – Ricky
    Commented Feb 18, 2014 at 20:44
  • @RickyBeam Yes, the /home is a mount point, so /home/shared and /home/dbz are on the same filesystem and even on the same mount point. All I do is bind-mount folders in /home/shared to folders in /home/dbz
    – dbzix
    Commented Feb 18, 2014 at 20:49
  • Seems this is a bug in gvfs. I've found an old bug description here and seems it still not fixed.
    – dbzix
    Commented Feb 18, 2014 at 22:07

4 Answers 4


This is a linux kernel issue. It's not looking at the true super-block of the source and destination filesystems:

17926 rename("d1/foo", "d2/foo")        = -1 EXDEV (Invalid cross-device link)

Looks like the issue is in do_rename() (fs/namei.c):

    error = -EXDEV;
    if (oldnd.mnt != newnd.mnt)
            goto exit2;


  • 1
    Thank you once again! I submitted an issue on bugzilla.kernel.org:
    – dbzix
    Commented Feb 19, 2014 at 11:05
  • I see that bug report went no where. I knew it would, some kernel devs are really quite thick. It's not an EXDEV as both mount points are the same dev. (I "fixed" this decades ago in my own tree, so one could recover deleted-but-still-open files from procfs -- ln /proc/<pid>/fd/# /real/location/file)
    – Ricky
    Commented Oct 21, 2018 at 21:32

In order to make a trash directory you need to be able to make .Trash_<uid> at the mountpoint (at least on Ubuntu when deleting from nautilus, your distro might use another directory). If that directory cannot be made because the parent is not writable by dbz, you will not be able to backup.

It should not be necessary to have the parent directory writeable, it suffices to create the .Trash_<uid> as root and then chown it to dbz.

I find it somewhat easier to test things regarding trash file creation using the gvfs-trash utility, which actually gives an Error if the file cannot be trashed. Use something like:

touch /home/dbz/work/test.txt
strace gvfs-trash /home/dbz/work/test.txt  2>&1 | grep .Trash | grep mkdir

to see which directory it actually tries to make.

  • 1
    Thank you for the answer. I created .Trash-1000 at /home/dbz and at /home/shared, and even at /home (and then owned by dbz), but no success. Your example gives me the following output: mkdir("/home/dbz/.local/share/Trash/info", 0700) = -1 EEXIST (File exists) mkdir("/home/dbz/.local/share/Trash/files", 0700) = -1 EEXIST (File exists) And doing gvfs-trash /home/dbz/123/1/ gives the following output: Error trashing file: Unable to trash file: Invalid cross-device link
    – dbzix
    Commented Feb 18, 2014 at 21:07

Do you have a symbolic link for any of the parent directories of the Trash directory to another filesystem. I had ~/.local/share/Trash soft linked to a directory on a different filesystem, which led to this error. Of course, it still should work, but a work-around is to keep the Trash on the same filesystem.

Also, I found that the Ubuntu trash from package trash-cli works with that symlink, whereas gvfs-trash which is used by gnome applications does not work.

  • thx on the trash-cli tip, an alternative on my answer may help :) Commented Aug 30, 2021 at 0:09

On nemo you can use this:
place this file at:

[Nemo Action]
Name=Move to Tra_sh(cli)
Comment=Trash even on mount binds
Exec=xterm -title "Trashing(cli)" -e trash -v %F

you can remove the xterm part and keep just the command.
you can change the shortcut but I suggest just pressing the context menu key over the files and just hit 's'.
I tested it with 1 file, many files, 1 folder and many folders selected, all worked!
I am quite sure this can work on nautilus too, I just dont remember where you should place an equivalent action.

PS.: related https://askubuntu.com/questions/1177100/how-to-fix-not-working-trash-on-bind-mounts-in-ubuntu-19-04-and-hide-them-in-n/1360837#1360837

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .