Issue with RMD and full path on vsftpd

[Anhubert]

Hi all,

I have following issue:

I login with FTPs, create a directory

MKD /somedir/ahutest

and then i delete it

RMD /somedir/ahutest

• works

now again, I create the directory

MKD /somedir/ahutest

then I log out and log in again and try to delete that:

RMD /somedir/ahutest

And I get

550 Remove directory operation failed.

now again, I create a directory

MKD /somedir/ahutest

change to that directory

CWD /somedir/ahutest

and create a subdirectory

MKD /somedir/ahutest/ahusubtest

Now I want to delete that dir immediate

RMD /somedir/ahutest/ahusubtest

And again

550 Remove directory operation failed.

It looks like Cyberduck is always using the complete path when doing commands as seen above. If I use Filezilla, it does

CWD somedir
CWD ahutest
RMD ahusubtest

and that works

So who has the bug, who has the problem and how to solve it? Is there a way to tell Cyberduck not to use the complete path in every command?

[dkocher]

We expect the server to handle absolute paths correctly. Do you know if you are using the latest version of vsftpd available?

[Anhubert]

latest is 2.3.5, I am using 2.3.0, because it is on Solaris and there is a precompiled package only for 2.3.0 available.

[Anhubert]

maybe the problem is, that he is changing into the directory and trying to RMD it while he is still in it:
CWD /somedir/test/test2
250 Directory successfully changed.
TYPE A
200 Switching to ASCII mode.
PASV
227 Entering Passive Mode (80,72,140,13,15,176).
LIST -a
150 Here comes the directory listing.
drwxrwsrwx 2 867 867 2 Jan 25 17:12 .
drwxrwsrwx 3 867 867 3 Jan 25 17:12 ..
226 Directory send OK.
RMD /somedir/test/test2
550 Remove directory operation failed.
RMD /somedir/test
550 Remove directory operation failed.

[dkocher]

Replying to Anhubert:

Good point, that is very possible. But the server has no reason to lock the directory and/or should handle this as it is a file system specific implementation detail. Can you report a bug against vsftpd as well, please. We only had a similar issue with Windows file servers before.

[Anhubert]

I already opened a ticket at vsftpd: ​http://viki.brainsware.org/forum/thread/80

And I did a trace on the vsftp trace while trying to delete the directory and indeed:

rmdir("/GenoPublisher/test")                    Err#22 EINVAL

The "Err#22 EINVAL" seems to be an error if you rmdir a busy directory

[Anhubert]

I finally found out, that this is indeed a serious Bug!

I tried it with an older version 3.4.1, there the problem does not occure, here the details:

CWD /somedir/test
250 Directory successfully changed. 
NOOP 
200 NOOP ok. 
STAT /somedir/test 
213-Status follows: 
drwxrwsrwx    2 867      867             2 Jan 26 01:30 . 
drwxrwsr-x    6 867      867            29 Jan 26 09:42 .. 
213 End of status 
PASV 
227 Entering Passive Mode (80,72,140,13,15,175). 
LIST -a 
150 Here comes the directory listing. 
drwxrwsrwx    2 867      867             2 Jan 26 01:30 . 
drwxrwsr-x    6 867      867            29 Jan 26 09:42 .. 
226 Directory send OK. 
CWD /somedir 
250 Directory successfully changed. 
RMD test 

And this is, how 4.3.1 acts: 
STAT /somedir/test/test2 
213-Status follows: 
drwxrwsrwx    2 867      867             2 Jan 26 11:28 . 
drwxrwsrwx    3 867      867             3 Jan 26 11:28 .. 
213 End of status 
CWD /somedir/test/test2 
250 Directory successfully changed. 
TYPE A 
200 Switching to ASCII mode. 
PASV 
227 Entering Passive Mode (80,72,140,13,15,167). 
LIST -a 
150 Here comes the directory listing. 
drwxrwsrwx    2 867      867             2 Jan 26 11:28 . 
drwxrwsrwx    3 867      867             3 Jan 26 11:28 .. 
226 Directory send OK. 
RMD /somedir/test/test2 
550 Remove directory operation failed. 
RMD /somedir/test 
550 Remove directory operation failed. 

So the difference is 3.4.1 is changing one directory up, before trying to delete:

CWD /somedir 

Please fix that bug.

[dkocher]

Regardless of the current working directory the directory should be deletable according to the FTP protocol specification. This is a bug in vsftpd which is locking the directory.

[dkocher]

Duplicate for #5865.