Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

UPD: finally an issue submitted to bugzilla.kernel.org

share|improve this question
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 Beam Feb 18 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 –  dbz Feb 18 at 20:49
Seems this is a bug in gvfs. I've found an old bug description here and seems it still not fixed. –  dbz Feb 18 at 22:07
add comment

2 Answers

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.

share|improve this answer
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 –  dbz Feb 18 at 21:07
add comment

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;


share|improve this answer
Thank you once again! I submitted an issue on bugzilla.kernel.org: –  dbz Feb 19 at 11:05
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.