17

The /home/users directory on my host is an NFS mount connected to a server which is not in my control. When deleting files in $HOME (/home/users/foo) with Nautilus I get the following message:

Cannot move file to trash, do you want to delete immediately?

The file "..." cannot be moved to the trash.

Is there some way to enable trash for this mount point? I have write access to the partition, but even after creating the expected /home/users/.Trash-$(id -u) and setting the sticky bit, Nautilus still fails to use the trash.

When reading this question and the Trash Specification I found that $HOME/.local/share/Trash is the standard location (unless $XDG_DATA_HOME is set), and it looks like Nautilus is only half-aware of this: It does indeed write a $HOME/.local/share/Trash/info/[filename]<.number>.trashinfo every time I try to delete a file, but the files are all empty and I still keep getting the error message.

Community
  • 1
l0b0
  • 9,271

4 Answers4

1

You are trying to set permissions for a file system that isnt recognized. THE SYSTEM FUNCTION that "deletes" is not the system used in a linux based bit unless its emulated. When you tell it to delete it tries to write to the "trashbin". You are only moving stuff. To remove it you need to access the file system, not raw data. Its going to kick the data back because you are just asking it to move not delete, the delete command isnt within its wheelhouse./ regardless of the command you use.

If you can mount the partition/drive of the server in samba or what ever you like you may be able to use that to delete. Try virtually mounting, with permissions. If you only have read/write but not delete/move your going to have a bad time.

Lester.Amod
  • 44
0

Nautilus' trash can looks virtually like one directory, but it's actually composed of two parts. A part for local files (on each NFS client) in $HOME/.local/share/Trash and another part for shared files on the NFS server in something like /home/users/.Trash-1002, with /home/users/ being the shared partition and 1002 being the numerical user id (as an example).

As in your case, your $HOME directory /home/users/foo is part of the shared partition /home/users, everything is completely shared, even the local files, and so even the local trash can. I can imagine this is confusing for Nautilus. Which trash can to use, the shared one or the local one?

Maybe your admin should consider mounting the shared drives as (symlinked) separate partitions, while keeping the $HOME directories local on each client. This way, users can still use the client even if the server fails, and it permits different distro's on each client. And most important: your trash can will work as expected.

So for example (on each client):

/home/foo      {local storage, $HOME}
/nfs/users/foo {nfs mounted storage}

ln -s /nfs/users/foo /home/foo/my_share

On the server, you or your admin can create a shared trash can with:

uid=$(id -u)
dir="/nfs/users/.Trash-$uid"
mkdir -m 02700 $dir
mkdir -m 00700 $dir/expunged
mkdir -m 02700 $dir/files
mkdir -m 02700 $dir/info
sudo chown -R $uid:$uid $dir

To activate, logout and login again on each client.

Epo Nym
  • 136
  • 7
0

uid=1000 en gid=1000 are required to make the trash work normally. Somehow you will need to mount it probably, is it possible to mount it in SAMBA like in fstab as below?

UUID=***********   /media/DATA     ntfs-3g defaults, uid=1000, gid=1000,  locale=nl_NL.UTF-8    0        0
Videonauth
  • 33,815
gerhas
  • 1
0

NFS uses UID (user id) and GID (group id) for permissions and I believe you need these to match on both the local and remote system to obtain the functionality you describe. This is unlikely to happen as you state "The server is not under my control"

Sources: http://forums.openmediavault.org/index.php/Thread/5827-nfs-and-trash/ http://linux.die.net/man/5/exports

Elder Geek
  • 36,752