Cannot upload to FTP server from particular computer

I have a strange problem.

I have an FTP server setup at work, on a LAN using zFTPServer. The server is configured to listen on standard port 21, and accept passive connections through ports 40000 to 40100.

The server is behind a D-Link DI-704 Router. The router is set to forward ports 21, and 40000 to 40100 to the internal IP of the computer hosting the server.

zFTPServer has numerous users setup with all of their various permissions and mount points.

All computers, both internally on the LAN, and external to the LAN can logo on and do everything within the constraints of their user permissions. All computers accept ONE.

When I log on as a user that has Read/Write/Upload/Download privileges from my home computer, I can do everything accept upload. I can download, create folders, delete files/folders, but I cannot upload. For some reason on this computer, when attempting to upload, the upload hangs upon the FTP server attempting to open a data connection after entering passive mode. After 30 seconds or so, the upload fails completely with a 500 error (Access denied). This makes no sense as I am logged on as a user with more than enough privilieges (read/write/delete/append for files; list/make/delete/+subdirs for folders).

The host computer is running Windows XP Pro, with Symantec Antivirus Corporate 9.0...that's it. Aside from the Server software itself, no other uneccessary software is installed. Windows Firewall is DISABLED.

What could possibly be stopping this one particular computer from being able to add data to the FTP server (that is the only thing not working...i.e., if i upload a zero kilobyte file, it is only when attempting to add physical bytes of data that this problem occurs)? It's almost as if the host computer is blocking my home IP address specifically from adding data, but I cannot find any evidence of this at the host computer itself. Could it be my specific Internet Connection from home (High Speed Cable)? I have no idea.

If anyone has any suspicions or suggestions, please let me know and it would be greatly appreciated.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

What other remote locations can upload to the server via FTP?  Could it be that no sites off company property are allowed to upload files into the intranet?

It would make sense for a company to block FTP uploads from the Internet.  FTP is an intrinsically insecure protocol because passwords are sent unencryoted, and an intruder often uses FTP to add hacking tools, root kits, trojans, backdoors, etc.  So even if you find a way to do this, your company SHOULD disallow it.  A far better procedure is to use secure FTP and SSH, so that you really know who is uploading stuff onto your server.
John-D-ChapmanAuthor Commented:
Anyone with a proper username and password both inside and outside of our intranet can carry out actions governed by the privilieges setup in the configuration of the FTP server.

It is just this one particular computer that I am unable to upload from, no matter what user I log in as.

Secure FTP and SSH is definitely the next step, and will hopefully occur sooner than later.

The computer hosting the server, although "plugged" in to our LAN, is not a member of our domain. So, even if a hacker got into to that computer, they would still then need to attain another username and password to gain access to any other resources on our network. Even if this compuer were compromised in the interim, losing the contents of the FTP site would not be catastrophic. I hoped this would provide enough "security" until software that provides Secure connections through SSL/TLS could be decided upon (or the software we are using releases a version supporting it, which is in the works).

So, the problem still stands, I cannot upload from one, and only one, particular computer outside our LAN. I cannot figure out what about this one computer is causing the access denial.
is the local account you use to log on to the ONE computer different to the account used for FTP ?
If so then it may be a credential issue.
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

Are there any interesting events in the error logs on that machine?
John-D-ChapmanAuthor Commented:

Yes, the local account on the computer in question is different than the account used to log on to the FTP server. But such is the case with everyone that logs on the to FTP server. In no situation does the account of the computer being used to log on the the FTP server have the same credentials as the FTP user itself.

User logs on to his/her computer as user "A", then logs onto the FTP site as user "B". The two sets of credentials have nothing to do with one another.

I have checked the error log, and there is nothing out of the ordinary in any section. There is also nothing extraordinary in the event viewer of the computer hosting the FTP server.

My home computer (the offending machine) is also hosting it's own FTP server using the same software (zFTPServer), and there are no problems the other way around..i.e. uploading/downloading/deleting from it. There are no common users between the two FTP servers (each server has a completely different set of users).

I apologize, as this may be something that is just impossible to pin down without the bility top sit down in front of the offending machine and assess. But, if anyone has any suspicions that lead to a solution, I will be super happy and ever appreciative.
Can you verify that when you are trying a connection from home that you are actually opening the data port in the range 40000 - 40100.

Are you behind a firewall at home ?
If yes - Does the firewall allow you to open this port ?

Are all the working users connecting from external networks ?

John-D-ChapmanAuthor Commented:
I have not verified what ports are actually being opened when trying to send data. i will check on this.

Yes, all users, with the exception of myself from within our LAN at wotk, are connecting from external networks.

I doubt, however, that any of them are behind a software firewall (as most would be connecting from workplace machines behind a firewalled router of some sort). At home I am running ZoneAlarm Professional. It may very well be that this is what is stopping me and I did no even think about it. Apologies for that. I will test this as soon as I get home tonight and report back.

Thanks very much for the nudge. I will get back to you to see if this is a resolution.
John-D-ChapmanAuthor Commented:
I have tested to see whether or not my software firewall (ZoneAlarm Pro) was stopping me from uoploading to my work's FTP site.

After shutting down the firewall completely (and checking that doing so did not turn the Windows Firewall ON), I was still unable to upload.

Next is to verify what ports are being opened to send the data. But I am not sure how to do that, so if someone has a suggestion, that would be great.
To see what ports are being opened, do these three steps:

1.  Open a command prompt and enter

     netstat -n

     You will see all the network connections your computer has open, usually there are several.

2.  Open your FTP session and try to transfer a file

3.  Return to the command prompt and enter

     netstat -n

     Compare it to the earlier list -- the new items are the ones the FTP session created.

However, if your FTP connection is failing, you may not see the ports there.  Here are two other tests to try-- PORTQRY and ETHEREAL:

Download and install PORTQRY from this site:

Then test your FTP connection with these two commands:

portqry -n -e 21

portqry -n -e 22

They should both be LISTENING.  If they are NOT LISTENING or FILTERED, something is blocking them.

ETHEREAL is a very powerful sniffer.  It is a bit complex to use at first, but it shows every packet your machine sends out and every packet it receives.  With Ethereal you can see exactly which request is not being responded to correctly.  You can download it here:

John-D-ChapmanAuthor Commented:
Thank you for the nudge on checking port status.

The 'portqry' command returned the following:

TCP port 21 (ftp service): LISTENING
TCP port 22 (unknown service): FILTERED

The 'netstat -n' command returned the following prior to logging onto the FTP site:

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    MyHomeIP:1075      ForeignIP:80        CLOSE_WAIT
  TCP    MyHomeIP:1079      ForeignIP:80        CLOSE_WAIT

After logon the command eturned the following:

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    MyHomeIP:1075      ForeignIP:80        CLOSE_WAIT
  TCP    MyHomeIP:1079      ForeignIP:80        CLOSE_WAIT
  TCP    MyHomeIP:1089      FTPServerIP:21    TIME_WAIT
  TCP    MyHomeIP:1091      FTPServerIP:21    TIME_WAIT
  TCP    MyHomeIP:1092      FTPServerIP:21    ESTABLISHED
  TCP    MyHomeIP:1093      FTPServerIP:21    ESTABLISHED

And finally, during an attempted upload:

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    MyHomeIP:1075      ForeignIP:80            CLOSE_WAIT
  TCP    MyHomeIP:1079      ForeignIP:80            CLOSE_WAIT
  TCP    MyHomeIP:1092      FTPServerIP:21        ESTABLISHED
  TCP    MyHomeIP:1093      FTPServerIP:21        ESTABLISHED
  TCP    MyHomeIP:1125      ForeignIP:80            TIME_WAIT
  TCP    MyHomeIP:1126      ForeignIP:80            TIME_WAIT
  TCP    MyHomeIP:1144      FTPServerIP:40000   ESTABLISHED
  TCP         TIME_WAIT
  TCP         TIME_WAIT
  TCP         TIME_WAIT
  TCP         TIME_WAIT

Is there anything glaring about what these commands have returned that I am missing?

Ethereal is a little over my head, but if it is suggested that I require it's use, I will try to figure it out.

Oops!  The ports for FTP are ports 20 and 21, not 21 and 22.  But even when FTP is working, it's port 21 that shows LISTENING.

Here is an article explaining how FTP works -- port 21 is used for control, and port 20 to send the data.

So although you can connect on port 21, something is blocking port 20, it seems.

Let's try this test.  I set up an FTP account on my server and uploaded something successfully -- let's see if you can do the same thing.

The server is
The username is u35755425-testftp
The password is testftp

I recommend that you use the Windows XP command-line FTP program just so you are doing exactly what I did.  Here is exactly what I did to connect and upload a file named 'kiooris.jpg' -- just a convenient file that was big enough to take a few seconds to transfer.


E:\Documents and Settings\Sam>ftp
Connected to
220 FTP Server ready.
User ( u35755425-testftp
331 Password required for u35755425-testftp.
230 User u35755425-testftp logged in.
ftp> send kiooris.jpg
200 PORT command successful
150 Opening ASCII mode data connection for kiooris.jpg
226 Transfer complete.
ftp: 472530 bytes sent in 4.97Seconds 95.10Kbytes/sec.


After logging in, I saw these items in netstat -n, and they remained the same during and after transfer:


During transfer, I saw this:


After transfer was complete, I saw this:


What happens when you try it?
Very puzzling!  I see that you do have a connection established with port 40000, which should be the data connection with your settings.  I don't see any reason for the data transfer to fail.

But anyway, please try my server.  If you cannot upload there, that might show us something.
It seems that your FTP is working correctly.
Your connections opened up are port 21 and 40000 as the data port which you specified is correct.

"The server is configured to listen on standard port 21, and accept passive connections through ports 40000 to 40100."

If you have access to the FTP server at work, then when you are in the office try and connect with the same account as you do remotely. Then try and copy/delete in the upload directory itself.
More than likely your account does not have rights or there is some problem with "inheritance" permissions which flow downwards from parent to child objects.

I have had this issue in the past and it was a crential/permissions problem on the account.
Not sure if it is your problem but give it a go.
By the way, can you try an account which does work from your machine at home.
John-D-ChapmanAuthor Commented:
samb39 and mianni,

Thanks very much for your help so far.

samb39, I will test an upload to your FTP server when I have a chance. I was puzzled as well because the netstat command told me that port 40000 had been opened for transfer. My router at work has 40000 to 40100 forwarding to the host computer. Port 20, however is NOT being forwarded. I did not think this necessary because I am specifying 40000 to 40100 in the FTP server's config for passive connections. Am I wrong? I will try this anyways (forward port 20) to see if this makes any difference.

mianni, connecting from the office, using the exact same account used to log on from home works without incident. In fact, anywhere I've tried, in or out of my office, and using the identical account, has worked without incident, except from home. So, I don't think credentials are a problem at all. This problem occurs no matter what user I log in as. There are multiple users setup with full Write/Upload privileges, including all subdirectories under their mount points (directories listed upon login).

Previously I had stated that ALL computers I had tested on except my home computer were trouble free. A new development: I have confirmed from another user that the problem is occurring for them as well. I initially thought it was an Active/Passive issue, because my FTP server activity log showed the PORT command, rather than a PASV command prior to a STOR attempt by them. However, I confirmed with the user that they were properly attempting to upload in passive mode. If an upload in passive mode fails, am I correct in assuming it will revert to Active mode (PORT) to try and execute the STOR, and only then if a failure occurs is it returned to the user?
John-D-ChapmanAuthor Commented:

I tested an upload from the command line to your FTP server with success. This made me decide to try an upload to my FTP server at work from the command line. I was successful. When I saw that the "send" command used PORT instead of PASV, I started to realize that the problem appears to be a PORT/PASV (Passive vs. Active) problem.

So, then I turned OFF Passive FTP in Internet Explorer and tried an upload, and again I was successful. This confirmed that I can upload using Active FTP, but cannot using Passive FTP. This is strange, since I am behind a software firewall at home, and the FTP server is behind a firewalled Router (from wat I've read, Active FTP should not work in this situation, hence the need for Passive mode).

I was successfull at uploading in Passive mode to your FTP Server, so based on that we can narrow my problem to either trouble wth the FTP Server itself (zFTPServer), or a problem with the way the Router is handling the Data Connection.

This would explain why I noticed that successful uploads in my activity log appeared to be after the PORT command, and those that were failing appeared to be after the PASV command.

Does it make any sense at all that I can upload using Active FTP and cannot using Passive FTP?
I have never used passive FTP.  I suppose the active FTP is working now, because you forwarded port 20.

This link, the same one I posted before, does explain the difference between active and passive FTP in great detail, but I don't really understand it myself.

I would guess that one of the later exchanges in figure 4 is failing, such as the Port X to port 21 in the next-to-last line.  That could explain why the file is created at zero bytes, but the actual data never gets through.  Debugging at this level is a job for Ethereal -- capture every packet in an attempted file upload, then compare the packets to figure 4 in that FTP explanation, and see what part went wrong.

But it's a long process.  It might be more practical to just leave port 20 forwarded and use active FTP.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
John-D-ChapmanAuthor Commented:

Thanks very much for all your help.

While I have yet to discern why some users cannot send data in Passive mode, those users seem to have no trouble in Active mode. So, at least data can now be sent, which was my main concern.

If I find the time to make a concerted effort at figuring out and translating Ethereal, I will do so. Until then, the main concern of reinstating the ability to send data to the FTP server has been rectified.

Thanks very much!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking Protocols

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.