fail to delete directory over sshfs with nautilus

[elatllat]

fail to delete non-empty directory over sshfs from nautilus by pressing the delete key. with "Error removing file: Operation not permitted"

works if you empty the folder first.

dir is "chmod -R 0777 folder"

mount command was "sshfs me@myServer:/ /media/myServer"

server:
2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009 i686 GNU/Linux
updated (not dist-update) Sun May 3 11:42:32 EDT 2009

client:
2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
updated Sun May 3 11:42:32 EDT 2009

it's like nautilus is asking for a "rm -f file" when it should be asking for a "rm -fr file"

[Martyn Ranyard (ranyardm)]

I can confirm this with same client, later server (Linux martyn-server 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux) and also with client and server Jaunty.

This is so annoying because sshfs is fantastic in every other respect.

[Bogdan Butnaru (bogdanb)]

I get the same behavior for my SSHFS mounts.

As the first poster mentions, this is strange because Nautilus can delete each individual file in the folder, and it can delete the empty folder afterwards. “rm -r" in the command line works flawlessly.

[Bogdan Butnaru (bogdanb)]

First, a work-around: create a folder named '.Trash' with permissions 1777 in the remote folder you're mounting.

However, this doesn't work in my case. A bit more detail:

I have a desktop called mabelode and a server called tanelorn.

On my Nautilus desktop (the same as my home folder) I have:
 - a folder called ~/mountpoints
 - inside this I have an empty set of directories following ~/mountpoints/tanelorn/mnt/corum
 - a symlink called ~/corum to ~/mountpoints/tanelorn/mnt/corum

On tanelorn there's a foldern /mnt/corum, which has a filesystem mounted on it. Both tanelorn:/ and tanelorn:/mnt/corum contain a folder named .Trash, owned by root:root with permissions 1777.

My username and uid is the same on both machines.

If I use “sshfs -o reconnect,transform_symlinks,allow_other,nonempty,fsname='sshfs#tanelorn:/mnt/corum' tanelorn:/mnt/corum ~mountpoints/tanelorn/mnt/corum” — that is, mount directly the mount-point on the server to the equivalent mount-point on my desktop — then trash works: the folder tanelorn:/media/corum/.Trash is recognized, Nautilus creates a folder called '1000' (my uid on both machines) inside it, and puts trashed files in there.

However, if I use “sshfs -o reconnect,transform_symlinks,allow_other,nonempty,fsname='sshfs#tanelorn:/' tanelorn:/ ~mountpoints/tanelorn/” — that is, mount the root of the server rather than a mountpoint on it — then: (a) trash works for files that are on the server's root filesystem, but (b) it doesn't work for files on other of the server's filesystems.

Presumably, Nautilus uses a 'move' command that only works inside a filesystem. In the second case, since all of the server's filesystems are accessed through the same sshfs mountpoint, Nautilus can't figure out that they're actually different, and doesn't try to use their respective .Trash folders. I'm not aware of any work-around for this situation, other than mounting each of the server's mount points separately.

[Sebastien Bacher (seb128)]

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

[huarewe (patrick)]

I am having the same issue.

Ubuntu 9.04
SSHFS on lan
Can't delete non-empty directories via nautilus.

[Robin van Leeuwen (robinvanleeuwen)]

Indeed this also affects me.

i mount a directory on the server on my client with sshfs.

sshfs <email address hidden>:/home/user /mnt -o reconnect -o big_writes -o compression=yes

In the directory /home/user on the server I can delete non-empty directories in Nautilus EXCEPT when
they are on a seperate (usb)disk (/dev/sdb1) that is mounted on /home/user/external_disk

"rm -r /mnt/external_disk/non_empty_directory" works fine.

In nautilus i first get "Cannot move to trash", "Operation not permitted"
when i choose "Delete immidiately" i get an "Error while deleting", "Operation not permitted"

The problem boils down to this:

Removing non-empty dirs in Nautilus works fine through sshfs when the dirs are on the same disk
as the mounted volume, but fail when removing non-empty dirs on a different disc than the mounted directory.

/mnt ---> sshfs@server:/home/user/externaldisc/ , then Nautilus remove 'subdir' works fine...
/mnt ---> sshfs@server:/home/user/ , then Nautilus remove 'externaldisc/subdir' fails...

kind regards,

[Emiel Molenaar (emiel-molenaar)]

Same issue here on 10.04 LTS, using sshfs over LAN.

[Robin van Leeuwen (robinvanleeuwen)]

It seems to be a problem in accessing the .Trash directory.

[Emiel Molenaar (emiel-molenaar)]

An up-to-date Maverick is also suffering this issue.

[Tory (tory-andrew-law)]

I am affected by this, Ubuntu 10.10

[Eric Carvalho (eric-carvalho)]

Same problem here.

Ubuntu Lucid and Maverick clients.
Debian Lenny server.

Creating folder .Trash with permissions 1777 in the remote folder solves the problem.

[elatllat (elatllat)]

Eric Carvalho, glad it's working for you.
Reading the comments makes me think it will not work for you if you try it on anything but the main file system of your server when you mount the main file system with sshfs.

[rshadow (rshadow)]

Create .Trash directory is not fix the problem. I think we need `rm -fr` for <Shift+Delete>.

[Tory (tory-andrew-law)]

Still affected by this Ubuntu 11.04

[Robin van Leeuwen (robinvanleeuwen)]

2011/4/17 rshadow <email address hidden>:
> Create .Trash directory is not fix the problem. I think we need `rm -fr`
> for <Shift+Delete>.

Indeed, creating a .Trash directory is not the answer. Nautilus gives
the option when i try to delete:

"Can't move to trash, do you want to skip op delete"

When i click delete, it deletes regular files just fine and empty
directories are also deleted fine.
Except non-empty directoties, those give the error "Permission
denied", but since i clicked "delete"
it should bypass the .Trash directory alltogether.

I don't think "rm -rf" is the answer either.
Because this isn't exactly the error which you'd expect when delete
when "rm -rf" would be the answer.

On a local filesystem:

rvl@home:~$ mkdir d
rvl@home:~$ touch d/f
rvl@home:~$ rm d
rm: cannot remove `d': Is a directory
rvl@home:~$ rmdir d
rmdir: failed to remove `d': Directory not empty

So something tells me that "rm -rf" won't work either, (and i guess
that rm -rf is already used)

man rm:
      -f, --force
              ignore nonexistent files, never prompt

So the -f won't fix a permission problem.

--
Robin van Leeuwen   |   http://www.rldsoftware.nl   |   Public Key:
http://www.rldsoftware.nl/key.txt

[Robin van Leeuwen (robinvanleeuwen)]

>2011/5/15 Robin van Leeuwen <email address hidden>:
> 2011/4/17 rshadow <email address hidden>:
>> Create .Trash directory is not fix the problem. I think we need `rm -fr`
>> for <Shift+Delete>.
>
> Indeed, creating a .Trash directory is not the answer. Nautilus gives
> the option when i try to delete:
>
> "Can't move to trash, do you want to skip op delete"
>
> When i click delete, it deletes regular files just fine and empty
> directories are also deleted fine.
> Except non-empty directoties, those give the error "Permission
> denied", but since i clicked "delete"
> it should bypass the .Trash directory alltogether.
>
> I don't think "rm -rf" is the answer either.
> Because this isn't exactly the error which you'd expect when  delete
> when "rm -rf" would be the answer.
>
> On a local filesystem:
>
> rvl@home:~$ mkdir d
> rvl@home:~$ touch d/f
> rvl@home:~$ rm d
> rm: cannot remove `d': Is a directory
> rvl@home:~$ rmdir d
> rmdir: failed to remove `d': Directory not empty
>
> So something tells me that "rm -rf" won't work either, (and i  guess
> that rm -rf is already used)
>
> man rm:
>      -f, --force
>              ignore nonexistent files, never prompt
>
> So the -f won't fix a permission problem.
> Robin van Leeuwen   |   http://www.rldsoftware.nl   |   Public Key:
> http://www.rldsoftware.nl/key.txt
>

This is all on natty (11.04) by the way

--
Robin van Leeuwen   |   http://www.rldsoftware.nl   |   Public Key:
http://www.rldsoftware.nl/key.txt

[Suco (sucotronic)]

I've made a quick workaround for my mates:
- install package python-nautilus
  sudo aptitude install python-nautilus
- download the attached file in the directory (create if it doesn't exists
  $HOME/.nautilus/python-extensions
- kill nautilus and next time, when you open it, you'll be able to delete folders in sshfs mounted servers through right click

[Donjan Rodic (bryonak)]

This bug is still present in 12.04 with Nautilus 3.4.2

[Curtis Lee Bolin (curtisleebolin)]

Still present in 12.10

[Felipe Castillo (fcastillo.ec)]

@Suco I downloaded your workaround, I created the directory python-extensions under .nautilus. Killed nautilus and still no luck deleting non empty folders.
Any other workarounds out there? it's pretty annoying!

[Suco (sucotronic)]

@Felipe, sorry, just now I can't test it. Maybe somebody with python skills can't help you to debug it ;)

[Deafboy (jan-registracie)]

Not sure if it's related to Nautilus in any way. Same behaviour in Files (Marlin) file manager.

[leschekfm (leschekfm)]

The issue is still present in 13.04

[Robin van Leeuwen (robinvanleeuwen)]

Not to be bitching about things or something, but i first posted this at 21
- 06 - *2010* , we're 3 years later and i still can't see a "Yo, this is a
problem which is gonna be fixed by *me / *him or her / isn't gonna be
fixed because it's a feature / whatever.... To get into some politics ,
whenever i install a new ubuntu i often get a nice GUI message when
something failes: "Would you like to submit a bug report" ..... Tell me,
why should i want that ?

2013/8/8 elatllat <email address hidden>

> ** Changed in: nautilus (Ubuntu)
> Status: Triaged => Confirmed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/371289
>
> Title:
> fail to delete directory over sshfs with nautilus
>
> Status in Nautilus:
> New
> Status in “nautilus” package in Ubuntu:
> Confirmed
>
> Bug description:
> fail to delete non-empty directory over sshfs from nautilus by
> pressing the delete key. with "Error removing file: Operation not
> permitted"
>
> works if you empty the folder first.
>
> dir is "chmod -R 0777 folder"
>
> mount command was "sshfs me@myServer:/ /media/myServer"
>
> server:
> 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009 i686 GNU/Linux
> updated (not dist-update) Sun May 3 11:42:32 EDT 2009
>
> client:
> 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686
> GNU/Linux
> updated Sun May 3 11:42:32 EDT 2009
>
> it's like nautilus is asking for a "rm -f file" when it should be
> asking for a "rm -fr file"
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nautilus/+bug/371289/+subscriptions
>

[Sebastien Bacher (seb128)]

> " we're 3 years later and i still can't see a "Yo, this is a problem which is gonna be fixed by *me / *him or her / isn't gonna be fixed because it's a feature / whatever"

Hi,

The issue is an upstream (the people who write this software) nautilus one, not specific to Ubuntu. The ticket in the nautilus project to track the issue is https://bugzilla.gnome.org/show_bug.cgi?id=565677

Ubuntu doesn't have the resources to deal with that bug at the moment (it's ranked low in our priority list since sshfs is not a standard configuration not something most of our users are running), patches are welcome if you want to work on it though. Otherwise you should try to comment on the upstream ticket, but it seems it's not ranked high enough in their priority list either...

[elatllat (elatllat)]

this might have just been fixed in that last commit to sshfs, we just need some testing and the new version in the repo

[robled (robled)]

I'm no longer able to reproduce this issue with Ubuntu 14.04. sshfs got a lot of love recently - it's extra great now!

[Curtis Lee Bolin (curtisleebolin)]

https://bugzilla.gnome.org/show_bug.cgi?id=565677