6

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 Beam Feb 18 '14 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 Feb 18 '14 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 Feb 18 '14 at 22:07
7

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;

*sigh*

  • 1
    Thank you once again! I submitted an issue on bugzilla.kernel.org: – dbzix Feb 19 '14 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 Beam Oct 21 '18 at 21:32
6

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.

  • 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 Feb 18 '14 at 21:07
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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