I'm having trouble with an FTP server, the FTP server is running on CentOS. The FTP server being used is VSftpd 2.0.5 ( I believe this is the default server that was installed with CentOS ). Prior to this, the server used to be on Windows ( FileZilla Server ), where we didn't have this issue and the FTP transfers were all very quick.

This only happens when doing an FTP GET or PUT into a network storage, if the file that I'm trying to FTP is being written or read from the local hard disk on the CentOS machine then it works lightning quick.

The network storage is mounted under centos using:

mount -o rw,vers=3 IP_HERE:/ftp /media/X

When I try to transfer to the network storage there is long delay somewhere and even though files are transferred very quickly, the overall transaction takes a long time. Unfortunately the network side ( firewalls etc ) is not within my control, but I'm looking for advise on what I need to ask the network team to trouble shoot when we look at this issue. It's been outstanding for a long time and previous attempts to resolve this issue have failed.

Here is an example of a send I just made ( to the network storage ), reported file transfer time is only 9 seconds, but the overall transfer took much longer than that. When transferring lots of small files, this delay obviously adds up and makes the overall transfer take a large amount of time.

13:47:50| put "test.img"
13:47:50| 200 PORT command successful. Consider using PASV.
13:48:22| 150 Ok to send data.
13:48:31| 226 File receive OK.
ftp: 33555060 bytes sent in 8.95Seconds 3747.49Kbytes/sec.

In the above example I initiated the ftp put command at 13:47:50, and the 200 response was instant. The 150 response came at 13:48:22, and then the transfer appears to have been completed quickly (~9 seconds ), as reported by the 226 response @ 13:48:31. There is exactly the same kind of delay using passive mode, between the STORE and the 150 response.

I guess really it boils down to what happens before that 150 response. Are we looking at a server configuration issue here? Or is it more likely to be firewall related? Any advise very welcome.


  • Consider using PASV. Did you try switching to PASV-mode? – Rik Jan 10 '14 at 13:05
  • Yeah I have, get the same kind of delay using PASV mode unfortunately – james4563 Jan 10 '14 at 13:28
  • 1
    Are you using ftp-client on Linux or Windows? Either way, could you try ftp -d x.x.x.x to connect in debug mode and see if the delay is right after the 200 PORT-line or after the ---> STOR-line? – Rik Jan 10 '14 at 13:40
  • Does the same delay happen when you do a second put right after the first. If it doesn't, and the second and subsequent other puts are faster, then it could be the problem DaveDeveloper describes. – Rik Jan 10 '14 at 14:57
  • Hi I see the exact same issue. What ended up fixing this for you? – Philip Brack Nov 3 '17 at 17:20

Yes it happens to me too. If you are using a client like FileZilla, you have to make sure that it doesn't disconnect after every file operation. Login takes a long time

  • Yes, it's very strange. Once the transfer actually starts it completes very quickly, as can be seen from my logging. It must relate to the network storage, but I don't know what the issue is and it's strange that it didn't occur on the Windows FTP server before moving to CentOS. – james4563 Jan 10 '14 at 12:41
  • If you are using cent OS, maybe you can use another FTP server. Like if you are using ftpd, try ProFTPD – Jim Gao Jan 10 '14 at 13:05
  • So you know the sequence when the user accesses your FTP server: – Jim Gao Jan 10 '14 at 13:08
  • User -> Your Router -> Your Computer -> FTPD -> Your harddrive – Jim Gao Jan 10 '14 at 13:08
  • This allows it to work but what is the problem. how can the performance be improved? – Philip Brack Nov 3 '17 at 17:21

while mounting VSftpd mount authentication happens first that would be the cause of the delay

I would use either create a samba share if you are using windows clients and/or nfs for the linux clients.

If you are stuck with ftp try using autofs mount. that might keep your mount alive in the back ground for you to reduce the initial connection delay.

also on VSFTPD seting you can look for logout delay or timeout delay and bump that up.

if you are using LDAP backend for authentication that might be the issue as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.