GNOME Bugzilla – Bug 565677
Nautilus cannot delete non-empty directories on sshfs fuse mounts
Last modified: 2014-03-30 21:17:05 UTC
Please describe the problem: When a directory on a remote host is mounted using the sshfs command, non-empty directories inside the mounted directory can't be deleted in Nautilus (as opposed to being moved to Trash) even when the user performing the operation has all the necessary permissions to do so. Steps to reproduce: 1. Start Terminal, create mount point somewhere inside current user's home directory (e.g. ~/mnt/mountname). 2. Mount home directory of same user on remote machine in LAN using sshfs (e.g. sshfs hostname: mnt/mountname). If required, confirm authenticity and enter password. 3. Create a new temporary directory (mkdir mnt/mountname/temp) and some file(s) inside it (ps >mnt/mountname/temp/ps.txt). Using ls -l, make sure the temporary directory and file(s) exist and have write permissions for the current user. 4. Open Nautilus, go to the temporary directory, select it, try to delete it using the (optional) Delete option in the directory's context menu or by pressing Shift+Del. 5. A dialog box with an error message appears in Nautilus: "Error while deleting. There was an error deleting mountname." Choosing the "Show more details" option will reveal the following text: "Error removing file: Operation not permitted." 6. Go back to Terminal window. Delete temporary directory with temporary file(s) inside it using the rm command (rm -r mnt/mountname/test). The directory and all its contents will disappear without any errors. 7. OR, in Nautilus, first delete the file(s) inside the temporary directory so that it is emptry, then delete the directory itself. Actual results: Expected results: Does this happen every time? Yes. Other information: I'm using Ubuntu 8.10, amd64 and i386 versions, on three different machines, all of them showing the issue described above. The problem was already present in Ubuntu 8.04. As a workaround, I have created a simple Nautilus script that allows me to delete any directory (empty or not, remote or local) via its context menu.
Corrections: Step 4: "the (optional) Delete option" => "the (optional) Delete command" Step 5: "There was an error deleting mountname." => "There was an error deleting temp." Of course we're trying to delete the temporary directory, not the mount point.
*** Bug 586875 has been marked as a duplicate of this bug. ***
Works fine here. Is this still occurring?
I'm running nautilus-3.4.2-5.fc17.x86_64 on Fedora 17, and this is still occurring, exactly as initially reported.
Still happens, as described in the initial report, with nautilus 3.6.3.
*** Bug 655159 has been marked as a duplicate of this bug. ***
Report in 2008, duplicate bugs in 2010 and 2011, people confirming this in 2012 and 2013... Yet the bug is still UNCONFIRMED? "UNCONFIRMED: This bug has recently been added to the database. Nobody has validated that this bug is true."
Although the bug's status is "UNCONFIRMED", this is still happening with Nautilus 3.8.2 under Fedora 19. I have to switch to the command line (and use rm -rf) every time I want to delete a non-empty directory on my sshfs mount.
I am also seeing this issue in Nautilus 3.10.0 on Arch. command line "rm -r" work fine.
We are almost at unconfirmed bug wooden jubilee :D (5 years) Since a nautilus developer marked a duplicate almost a year ago, the problem seems to be known. I am curious to hear why this is a problem to fix. Maybe the error was reported to the wrong package? Maybe it's not in Nautilus' hands? Although the workaround is known: Nautilus should internally delete files first and then delete empty directory for sshfs.
Don't read too much into the "UNCONFIRMED" word. Or any other status word for that matter. They are interesting only for internal organization. In theory, someone would review all bug reports and, if confirmed, change their stauts to "NEW". But in practice this isn't happening systematically, so UNCONFIRMED or NEW makes little to no difference.
This is a problem with sshfs that has now been fixed. See the last few comments in bug 541714.