Pure-Ftpd Not Working on cPanel 11.52

[vipin]

Hi,

After upgrading cPanel to 11.52 , Pure-ftpd is no longer working . Only ProFTPD works.

--------

Error: Could not connect to server
Status: Waiting to retry...
Status: Resolving address of ftp.testdomain.com
Status: Connecting to XX.XX.XX.XX:21...
Status: Connection attempt failed with "ECONNREFUSED - Connection refused by server".
Error: Could not connect to server

-------------

In some server it is showing 100% CPU usage.

-------------

PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEM  TIME+  COMMAND 
3197 root  20  0  133m 2148 1644 R 100.0 0.0  1:38.24 /usr/sbin/pure-ftpd --daemonize -A -c50 -B -C8 -D -E -fftp -H -I15 -lextauth:/var/run/ftpd.sock -L10000:8 -m4 -s -S21 -U133

----------

/usr/sbin/pure-ftpd --daemonize -A -c50 -B -C8 -D -E -fftp -H -I15 -lextauth:/var/run/ftpd.sock -L10000:8 -m4 -s -S21 -U133:022 -u100 -i -Oxferlog:/usr/local/apache/domlogs/ftpxferlog -k99 -Z -Y1 -J-ALL:-SSLv2:!aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:AES256-SHA:AES128-SHA:DES-CBC3-SHA

----------------------

 

[24x7server]

Hello ,

I think you are using filezila FTP clients. Are you getting same issues with other FTP clients ? Also Please check your FTP logs and let us know what error are you getting in logs file.

 

[uid03]

we have the same issue. Unfortunately we are forced now to switch to ProFTP. Please fix it asap.

 

[cPanelMichael]

Hello

Please check the output of the following command:

grep CallUpload /etc/pure-ftpd.conf

Also, have you installed any third-party applications such as CXS on your system (even if you have since uninstalled that application)?

Thank you.

 

[uid03]

grep CallUpload /etc/pure-ftpd.conf

#CallUploadScript yes

we have no third party software installed.

 

[cPanelMichael]

Please also post the output from:

grep CallUpload /var/cpanel/conf/pureftpd/main

Do you notice any error messages in /var/log/messages when restarting PureFTPd?

Thank you.

 

[morrow95]

Fairly new server. All of a sudden I can no longer connect to ftp with TLS/SSL Explicit encryption - this is after it worked fine for a few weeks. As I am going nuts trying to figure out what is wrong I noticed it is only happening for a few ftp clients. WinSCP and FileZilla connect fine, whereas CuteFTP and MS Expression Web (both older software) no longer do. This made things even stranger because it is the exact same connection settings so I didn't understand how this was possible.

Today, while looking through the settings of my CuteFTP client I noticed a setting called 'reuse cached session for data connection (required for some servers)'. Upon turning this setting ON I can now connect again with no issues from CuteFTP.

The problem here is MS Expression Web does not have such a setting to turn on.

With all of this said, is there some setting that I might have changed within WHM and/or pureftpd that would cause this to happen? I guess what I am asking is if there is some way to force this 'reuse cached session for data connections' on my server instead of needing to do so in the client. I find it really strange that everything worked fine for quite some time then all of a sudden nothing, but only for those two clients, then on top of that this setting solves the issue.

There must be a setting or something on the server side of things to correct this. I don't remember changing anything in regards to this, but it would seem something was changed since it worked fine for a few weeks until the other day.

 

[rs-freddo]

same problem, pure ftp works but the reconnects on every file upload / download - basically unusable except for small files. Various clients. No fancy setup and using passive mode.

grep CallUpload /var/cpanel/conf/pureftpd/main

shows nothing

 

[cPanelMichael]

We have an internal case open (CPANEL-2039) that is potentially related to the issue you have described. Could you browse to "WHM Home » Service Configuration » FTP Server Configuration", and set "Broken Clients Compatibility" to "Yes"? If this does not help, please open a support ticket using the link in my signature so we can take a closer look. You can post the ticket number here so we can update this thread with the outcome.

Thank you.

 

[rs-freddo]

"Broken Clients Compatibility" is set to "Yes"

 

[cPanelMichael]

"Broken Clients Compatibility" is set to "Yes"

Were you able to open a support ticket so we can take a closer look?

Thank you.

 

[morrow95]

FIXED - it turns out there is a 'bug' with 11.52 which causes this. There is an internet open case for it, but no timeframe as to when it will be fixed. The solution in the meantime is to enable the 'broken clients compatibility' setting and it will work as normal again.

 

[Serra]

Setting "Broken Clients" fixed the issue for me with WS_FTP Pro. It also doesn't appear to have broken any of my existing clients that were working prior to the update.

 

[cPanelMichael]

To update, the it's been determined the issue here is with the individual FTP clients rather than the server configuration. RFC compliance requires the same TLS session used for both control and data connections. The suggested solution is to browse to "WHM Home » Service Configuration » FTP Server Configuration", and set "Broken Clients Compatibility" to "Yes" to workaround the issue with the FTP client.

Thank you.

 

[Metro2]

I don't know if this will help in narrowing down the issue at all, but it's worth a share...

I just got brand new servers and same issue, but the problem does not happen on all my older servers using the same exact FTP client - FileZilla latest stable - and on the servers themselves; the same exact WHM/cPanel version, same exact FTP config, same exact... well, basically everything in regard to WHM/cPanel/FTP.

The DIFFERENCE is that this NEW servers where I'm encountering this are running CloudLinux 6.7 with the common features enabled (cagefs,php select,mysql gov,lve manager) , and the OLDER servers that I'm migrating away from where I've never encountered this issue are running RHEL 5.

Setting "Broken Clients Compatibility" to "Yes" is a successful workaround for me. I guess that's going to be standard practice on any new CL boxes for now.

Hope maybe this info rings a bell with someone somewhere...