Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have an IIS FTP site on a Windows Server 2003 x64 machine.

Application Layer Gateway service is disabled (so does not apply). Windows Firewall service is disabled as well. Connection timeout for the FTP site (there is only one) is set to 1,200 seconds = 20 minutes.

An external client can connect to the site, list directory contents and download small files. When a client attempts to download a large file (eg, if the download continues for 3 minutes, which is still under 20 minutes, but relatively long), the server sends all data, then the connection times out, the client issues REST / RETR commands attempting to restart the download since after the last byte (which I believe should succeed and receive exactly 0 bytes), and the server behaves as if the client tried to restart after byte 0, that is, it sends the entire file all over.

Any ideas on how to fix this?

share|improve this question

Try downloading the file from the server itself and then try downloading the file from the same network as the server. If it works on the server then you may have a network issue, if it works from the network then you may have a firewall or router issue.

share|improve this answer
The download works both from the server and from another machine on the same network, but that can be only because the download goes too fast to hit the timeout that normally occurs. I don't have a file that is big enough to download locally for more than about 20 seconds, so I can't say for sure whether the timeout issue will occur in either of the above cases. Any other ideas? Thanks for the reply. – accel229 Sep 29 '09 at 12:58
Put a file on the FTP server that's big enough to take 3 minutes or more from the server and the local network. The key is to try to replicate the problem internally to determine if it's related to the server, the local network, the router\firewall, or something between your network and the client. – joeqwerty Sep 29 '09 at 13:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.