After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 541714 - Wrong error code when deleting non-empty directory
Wrong error code when deleting non-empty directory
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: sftp backend
unspecified
Other All
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-07-05 20:41 UTC by Julien Olivier
Modified: 2014-01-08 09:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Julien Olivier 2008-07-05 20:41:02 UTC
Please describe the problem:
(This bug was first reported on Ubuntu's launchpad here: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/244779)

If I connect to my SSH server using GNOME's "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.

The SSH server is an Ubuntu 5.10 with openssh-server, and the bug only occurs when trying to remove a folder which is located inside an SMB mount point.

Here is the configuration of my SSH server:

I have an account named "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 no files get 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.

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

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Cosimo Cecchi 2008-07-14 23:43:41 UTC
-> gvfs

This seems to be an issue in the gvfs backend.
Does gvfs-rm ssh://uri-of-your-file from a terminal work?
Comment 2 Julien Olivier 2008-07-19 14:31:49 UTC
If I run this command on the folder (still containing files), I get the following error:

Error deleting file: Permission denied

If, however, I run the command on all the files inside this folder, the files are successfully removed. If, then, I run the command on the folder (now empty), the folder is successfully removed.
Comment 3 ville.ranki 2009-01-27 14:41:01 UTC
I confirm that this bug exists in Gnome 2.22.3 on Ubuntu Hardy, but has been fixed in Gnome 2.24.1 on Ubuntu Intrepid.
Comment 4 Alexander Larsson 2009-03-10 15:09:32 UTC
Its just reports the wrong error (due to sucky sftp protocol wrt error reporting). We report permission denied instead of directory not empty.
Comment 5 Julien Olivier 2010-07-16 08:08:46 UTC
Has it been fixed? I can't reproduce it as I don't have access to this server anymore. I just ask so that the bug can be closed and doesn't stay "unconfirmed" forever.
Comment 6 ville.ranki 2010-07-16 09:54:43 UTC
Seems to be fixed on Ubuntu Lucid (Gnome 2.30.2).
Comment 7 ville.ranki 2011-06-20 18:04:25 UTC
This happened to me again in Ubuntu Natty (Gnome 2.32.1). Possible regression?

$ ls -l sftpmount/directory
total 17992
-rwxrwxrwx 1 user user 6593696 2008-12-29 07:23 file.ext

If i select the directory in nautilus, i get confirmation 
"cannot move to trash..". If i click "Delete" i get "Error removing file: Operation not permitted"

But on console:

$ rm -rf sftpmount/directory
$

The directory is mounted with sshfs options:

Cipher="blowfish",allow_other,idmap=user,uid=1000,gid=1000,workaround=rename

Can anyone confirm?
Comment 8 Felix Möller 2012-02-26 00:06:46 UTC
For me this works.

fm@thinkpad:~/thesis$ LANG=CC gvfs-rm sftp://root@nas-local/DataVolume/shares/data/dir
Error deleting file: Folder is not empty
Comment 9 ville.ranki 2013-08-11 00:07:15 UTC
This just happened again on gvfs 1.16.1-0ubuntu1. Deleting directory with Nemo says permission deleted, deleting with rm -r works.
Comment 10 Ondrej Holy 2013-08-14 10:36:40 UTC
(In reply to comment #9)
> This just happened again on gvfs 1.16.1-0ubuntu1. Deleting directory with Nemo
> says permission deleted, deleting with rm -r works.

Are you able to reproduce it using gvfs cmd tools, e.g.:

$ gvfs-mkdir sftp://user@localhost/path/a
$ gvfs-mkdir sftp://user@localhost/path/a/b
$ gvfs-rm sftp://user@localhost/path/a
Error deleting file: Directory not empty

because this doesn't reproduce it for me...
Comment 11 Ross Lagerwall 2013-11-07 16:57:41 UTC
Yes, it seems to be fixed.

Comment 7 refers to removing a non-empty dir on a fuse-mounted sshfs.

Eg: try:
sshfs user@host: directory
gvfs-rm directory/nonemptydir
Error deleting file: Error removing file: Operation not permitted

The issue is that gvfs-rm does an rmdir() which sshfs returns as EPERM (from the manpage: The file system containing pathname does not support the removal of directories.) rather than the standrd ENOTDIR or EEXIST.

This seems to me to be a problem with sshfs rather than gio.
Comment 12 ville.ranki 2013-11-08 09:24:31 UTC
Thanks for investigating the issue. Could you send a bug report to fuse-sshfs@lists.sourceforge.net to get the issue fixed? AFAIK they don't have a real bug tracker.
Comment 13 Ross Lagerwall 2013-11-08 10:02:43 UTC
OK, done.
Comment 14 Ross Lagerwall 2014-01-08 09:06:11 UTC
(In reply to comment #12)
> Thanks for investigating the issue. Could you send a bug report to
> fuse-sshfs@lists.sourceforge.net to get the issue fixed? AFAIK they don't have
> a real bug tracker.

FWIW, this has been fixed in fuse-ssh git with commit 91c1f2ba9e02a0eacb2ac46e87230a2709df2038.

http://sourceforge.net/p/fuse/sshfs/ci/91c1f2ba9e02a0eacb2ac46e87230a2709df2038/