Centos – proFTPd w/ MySQL Auth, behind NAT – Failed to retrieve directory listing

centosftpproftpd

I am running proFTPd on my CentOS linux VM (which is behind NAT).

This is my proftpd.conf configuration so far: http://pastebin.com/raw.php?i=X8rXYbSJ

When ever I connect to the ftp account in FileZilla client, I am getting the following:

Status: Connecting to 109.xxx.xx.xxx:2121...
Status: Connection established, waiting for welcome message...
Response:   220 FTP Server Ready.
Command:    USER exampleuser
Response:   331 Password required for exampleuser
Command:    PASS ******
Response:   230 User exampleuser logged in
Command:    SYST
Response:   215 UNIX Type: L8
Command:    FEAT
Response:   211-Features:
Response:    MDTM
Response:    MFMT
Response:    LANG ja-JP;ko-KR;bg-BG;zh-TW;en-US;ru-RU;it-IT;fr-FR;zh-CN
Response:    TVFS
Response:    UTF8
Response:    MFF modify;UNIX.group;UNIX.mode;
Response:    MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
Response:    REST STREAM
Response:    SIZE
Response:   211 End
Command:    OPTS UTF8 ON
Response:   200 UTF8 set to on
Status: Connected
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Type set to I
Command:    PASV
Response:   227 Entering Passive Mode (109,xxx,xx,xxx,237,74).
Command:    MLSD
Error:  Connection timed out
Error:  Failed to retrieve directory listing

I've looked in /var/log/proftpd/ folder and it's empty.

I found the following in this file /var/log/messages:

Oct 29 12:34:33 mageDev proftpd[27542]: 127.0.0.1 - ProFTPD killed (signal 15)
Oct 29 12:34:33 mageDev proftpd[27542]: 127.0.0.1 - ProFTPD 1.3.3g standalone mode SHUTDOWN
Oct 29 12:34:34 mageDev proftpd[27560]: 127.0.0.1 - ProFTPD 1.3.3g (maint) (built Sat Sep 14 2013 20:13:10 UTC) standalone mode STARTUP
Oct 29 12:34:53 mageDev proftpd[27562]: 127.0.0.1 (::ffff:46.xx.xxx.xx[::ffff:46.xx.xxx.xx]) - FTP session opened.
Oct 29 12:34:53 mageDev proftpd[27562]: 127.0.0.1 (::ffff:46.xx.xxx.xx[::ffff:46.xx.xxx.xx]) - Preparing to chroot to directory '/ftp/exampleuser'

How can I diagnose this error/problem? Why is it throwing the error Failed to retrieve directory listing?

This is the server folder for this exampleuser:

enter image description here

I realise a similar question like this already asked here: proftpd, dynamic IP, and filezilla: port troubles

Unlike this user, if I remove my MasqueradeAddress I get this warning and still same error:

Status: Server sent passive reply with unroutable address. Using server address instead.
Command:    LIST
Error:  Connection timed out
Error:  Failed to retrieve directory listing

Best Answer

You get the "Failed to retrieve directory listing" error message because the FTP client does not get the directory listing from the server, most likely due to a firewall or network issue.

The FTP protocol was invented long before network firewalls and Network Address Translation, and it uses a separate command channel and data channel for the communication.

When you log in, only the command channel is in use.

When you perform a directory listing, the client and server tell each other on the command channel on what IP address and port (60746 in your example) the data channel should be dynamically set up on for the transfer of the directory listing data.

This is done with the FTP command PORT or PASV.

In your case, the client issue the PASV command, and the server replies with: 227 Entering Passive Mode (109,xxx,xx,xxx,237,74).

The first 4 octets within the parenthesis make the IP address, and the last two the port number (256*237 + 74 = 60746).

Are you running the FTP server inside a virtual machine with a NAT-style network adapter configured for the virtual machine (as opposed to Bridged)? Then this is most likely the cause of your problems, because those kinds of VM:s are usually not reachable from "the outside", since they share the physical host's IP address.

Are ports 60000-65535 open on the server? Your config specifies that range to be used for passive connections. You can narrow it down to a shorter range to require fewer open ports in the firewall.

Related Topic