Thread: Cute FTP Error

Got a pastebin of the logs? It's kind of hard to tell what's wrong from the short logs you posted. Server side logs would be better, as it seems the server is disconnecting you for some reason. Should be kept in /var/log (for Debian anyhow, I think Ubuntu is the same). I've heard some rumblings of recent issues with FTP clients due to TLS renegotiations, but it shouldn't apply to this since you are being disconnected immediately. Is it possible you are setting your default directory to somewhere you don't have permission to enter in the FTP conf?

FTP debugging is probably the third most asked new user question on our service ( after "Why isn't it really, really fast?" and what is the "RUTorrent says 100% Memory/CPU, What is up with that?"), and number one in time spent answering.


Both Darkslider and Blackhat have approached this systematically, you need to do some debugging. And Xirvik, though not the most helpful tend to competent, if not very competent. Regretfully, Xirvik appears to be saying "Not our problem."


First, understand the basics of FTP, there is one control channel, this is used to tell FTP what you want to do, command & control. Then there are multiple data channels, one is opened each time to transfer data between the server and you.

How data connections are opened is determined by the mode of FTP. Two modes, passive and active, in passive mode your server opens a bunch of data connections, and tells you which one to use. In active mode the server opens a connection that is provided by client FTP app. So passive refers to the client application, does it actively provide connections. For this reason passive is most common, you don't need a hole in your firewall, or ports forwarded to handle passive, all the logic is on the server.

As Herr Slider says, you put encryption on top of that, either SSL or TLS. Unless this is explicitly set in the server configuration, the encryption is only on the control channel, the data channel is cleartext.


Most seedbox vendors provide FTP thru one of three packages, ProFTPD, vsftpd, ore pureftpd. Each has their advantages and disadvantage. ProFTPD is the oldest, and crankest., most resource intensive. VSFtpd is the lightest weight, easiest to configure, but has compatibility issues especially around encryption. PureFTPD is in the middle, very flexible, but like a flight cockpit with all the labels peeled off, a major pain to configure, there is no simple default configuration.

So from cuteftp message, it appears as though the control channel is just dropping. You need to know why, to do that you need to, as Black Hat suggests, look at the system server logs. The logs are not public readable, and they are most likely in the directory '/var/log/proftpd', of the logs that proftpd keeps, you want the system log. Here is a mini-HowTo on logging for Pro.

If you don't have access to these logs, ask Xirvik to send them to you. Generally seedbox vendors like specific tasks that are straight forward, so you shouldn't have an issue. They hate questions like "Why isn't it working?", "Why is it slow?" , "What is your home address?" - the more a question is a short definable, achievable goal, the better.

Ideally you want to look at the log, then induce your failure and look again, see what it claims are its reasons for dropping the control connection.

There are a few things you can do that might further illuminate this, that don't require a access to the logs. These are basic debugging, eliminatory steps. When debugging systematically, you want to identify which of the parts is having a problem, in this case there are three to four parts, by eliminating them you can see where to focus:

• is it the server, proftpd? [low probability]
  
• is it the client, cuteftpd?
  
• Is it your network connection?
• Is it your home machine?
  

You can eliminate them thru simple comparison and eliminate it as the source of the problem, try a different client, like FileZilla. Try another machine at home. Ask someone here on a different network to see if they get different results (change the password afterwards). In this way you can see if it is CuteFTP, The network, your machine, or what is left over, the server. Seedbox vendors like it when you have done your homework, and will be much more willing to work on a solution if you tell them where you think the problem is.


Hope this helps.

Another possibility I found while I was searching around on an unrelated issue was with vsftpd, but the same concept should apply.

The 2 common errors they mentioned were:
1) chroot.list didn't exist, you can't be chrooted without such a list.
2) chroot directory didn't exist

You may have one of these two issues