permission denied when removing a directory via SSH

[Julien Olivier]

Binary package hint: gvfs

If I connect to my SSH server using the "connect to server" function, it pops up Nautilus and shows my folder. Now, if I try to remove a file in the folder, it works prefectly. But if I try to remove a directory, it fails with a "permission denied" error message. However, if I log into my SSH server using the "ssh" command in a terminal, I can perform an "rm -rf" on the said directory and it works flawlessly.

PS: the bug appeared in Hardy Heron, but it used to work perfectly in Gutsy Gibbon (which, I think, used gnome-vfs instead of gvfs).

ubuntu: 8.04.1
gvfs: 0.2.4-0ubuntu2
nautilus: 1:2.22.3-0ubuntu2

[Sebastien Bacher (seb128)]

thank you for your bug report, not confirming that works correctly on my hardy, what ssh server do you use?

[Julien Olivier (julo)]

The SSH server is an Ubuntu 5.10 with openssh-server. But, doing some more tests, I discovered that the bug actually only occurs when trying to remove a folder which is located inside an SMB mount point.

Here is my configuration:

I have an account name "public", with a home folder in "/home/public" (drwxr-xr-x public public)

On startup, I run the following:
mount -t smbfs -o username=XXX,password=XXX,ip=XXX,iocharset=utf8,uid=public,codepage=cp437,gid=public,rw //XXX/share /home/public/share

So, I then have a "/home/public/share" which is a SMB mounted folder (drwxr-xr-x public public).

Then, I create a folder "test" in "/home/public/share" with a bunch of folders and files inside (all belong to public.public with "rw" rights).

Now, if I try to remove this folder with Nautilus, I get a "permission denied" error and not file gets removed. But if I run "rm -rf test" from the CLI (logged as "public" user), it works fine.

If, however, I move the "test" folder from "/home/public/share" to "/home/public", I can remove it from Nautilus without any "permission denied" error.

PS: would it help if I set up a test account and a test SMB share ?

[Sebastien Bacher (seb128)]

the setup seems to be quite specific, could you open the bug directly on bugzilla.gnome.org? the ubuntu desktop team has a lot to do and I doubt somebody will work on this issue in a distribution specific way soon, the bug would be better sent on bugzilla by somebody having the issue who can reply to their comments

[Connor Imes (ckimes)]

Thank you for reporting this bug. FYI, 5.10 Edgy Eft is no longer supported, so it is unlikely that any official source will help you with it until you upgrade to a supported version of Ubuntu.
Is it possible that it simply won't let you move the folder to the trash bin (though I would expect a different error)?
Just my .02, I'll let Sebastien finish taking care of you.

[Julien Olivier (julo)]

OK, I'll open an upstream bug report.

Thanks for your time.

[Connor Imes (ckimes)]

Julien, can you please post a link to the upstream bug report and I will attach it to the bug here so we can track it as well. Please include the gnome bug number as well. Thank you.

[Julien Olivier (julo)]

I reported it with all the details on GNOME's bugzilla here: http://bugzilla.gnome.org/show_bug.cgi?id=541714

[Ville Ranki (ville-ranki)]

I just tested, and this seems to be fixed on Intrepid. Hardy is a LTS release, so i guess this should be fixed in it also.

[Sebastien Bacher (seb128)]

does anybody still get the issue on jaunty?

[Julien Olivier (julo)]

I don't have the issue anymore on intrepid, but I can't test jaunty for the moment.

[Sebastien Bacher (seb128)]

closing the bug since that works correctly now

[Ville Ranki (ville-ranki)]

I just saw this bug again on Karmic, reopening.

[Sebastien Bacher (seb128)]

don't reopen closed bugs because you have a similar issue open a new one rather

[Ville Ranki (ville-ranki)]

This still happens in Oneiric.