• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question 3CX FTP backups fails since upgrading to 17.8

mr-wolf

Silver Pleskian
Plesk Guru
For more than a year I'm backing up 3CX configs to a Plesk server which started to fail recently
It was since I upgraded from 17.5 to 17.8

I'm using Passive FTP which is working fine when using a normal FTP-client.
Plesk's tutorials even took over my way of changing the config to allow passive FTP by using an extra file in /etc/proftpd.d/passive_ports.conf

I have IPv6 disabled, so I changed the xinetd config accordingly.

When I use tcpdump -A host xxx.xx.xx.xx I noticed that the 3CX FTP client invokes EPSV (enhanced passive mode). I was hoping this was the key to the problem I was having. I needed a lot of research to find out how to turn off that, but that didn't work either...

220 ProFTPD Server (ProFTPD) [xx.xx.xx.xx]
USER blabla
331 Password required for blabla
PASS secret
230 User blabla logged in
FEAT
211-Features:
AUTH TLS
CCC
CLNT
EPRT
EPSV
HOST
LANG en-US*
MDTM
MFF modify;UNIX.group;UNIX.mode;
MFMT
MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.groupname*;UNIX.mode*;UNIX.owner*;UNIX.ownername*;
PBSZ
PROT
REST STREAM
SIZE
SSCN
TVFS
UTF8
211 End

OPTS UTF8 ON
200 UTF8 set to on
TYPE I
200 Type set to I
SIZE /httpdocs/folder/backup.zip
550 /httpdocs/folder/backup.zip: No such file or directory
EPSV
501 EPSV: Operation not permitted
PASV
227 Entering Passive Mode (xx,xx,xxx,xx,194,130).
STOR /httpdocs/folder/backup.zip
150 Opening BINARY mode data connection for /httpdocs/folder/backup.zip
(client sends data)
426 Transfer aborted. Interrupted system call

The ports that are used for sending the data corresponds exactly with the ones I opened up in the firewall

cat /etc/proftpd.d/passive-ftp.conf
# Global section
<Global>
<Limit EPSV EPRT >
DenyAll
</Limit>
PassivePorts 49152 49852
</Global>

iptables-save | grep 49152
-A INPUT -p tcp -m tcp --dport 49152:49852 -j ACCEPT

cat /etc/xinetd.d/ftp_psa
#ATTENTION!
#
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST AFTER YOU UPGRADE PARALLELS PLESK PANEL.

service ftp
{
flags = IPv4
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
instances = UNLIMITED
server = /usr/sbin/in.proftpd
server_args = -c /etc/proftpd.conf -S 0.0.0.0
env = LC_ALL=C LANG=C
}

It also didn't work before I turned of enhanced passive mode...

I would like to stress that a Filezilla Passive FTP client has no problems whatsoever uploading and downloading from this server...

I also opened up everything coming from that IP in the firewall...

I ran out of options and don't know how to get it working again.
Maybe I'm going to back-up to somewhere else.
They don't even support secure FTP
 
That bug seems to be tied to usage with SSL. Mine are plain FTP's.
With such an old protocol one would think there are no implementation problems of this kind.
 
hmm, interesting... Anyway, I am still thinking that the issue not in Plesk.

Could you please collect debug data for ProFTPd in your environment or provide output of `# plesk version` and steps to reproduce the issue?
 
hmm, interesting... Anyway, I am still thinking that the issue not in Plesk.
No, Plesk is not a suspect.
But I assume Plesk upgraded some packages.

Maybe it's xinetd ?
What happened that it needed the IPv6 changed to IPv4?
Having no ipv6 at all I found it strange it was always in there and working.

I'm going on holiday and today I'm rounding up everything...
It will have to wait..
 
More than a year I am unable to create FTP-backups of my 3CX-server using our Plesk servers.
This all happened after Plesk decided to upgrade their ProFTP with a version they compiled on Feb 20 2018.

I would really like to have this issue resolved, but none of the direct parties are recognizing the issue (ProFTP / 3CX)
It could well be that if Plesk compiles ProFTP to a current one this problem is solved.
A while ago I tried this myself, but I was not able to get a properly working ProFTP-server.

Is there some way Plesk can provide me an updated ProFTP package that I can test?
If that version would work with 3CX I can give feedback on that and Plesk can then distribute it with all of their versions.

I created these issues, but nothing has come from it:

426 Transfer aborted. Interrupted system call · Issue #774 · proftpd/proftpd
3CX FTP back-up does not work anymore ever since ProFTPD updated on May 7th 2018


Please, please help!!!
 
I configured some of the 3CX-servers to back-up locally, but several were still configured to back-up using FTP.
Only recently did I notice that all those back-ups became successful.
Nothing happened in these 2 years...

At first I thought that this was due to a change of ProFTPd on my server. In 2018 I was running 1.3.6 and currently I'm running 1.3.6c which was compiled in 2020.
I then inspected my mail for the back-up reports of my 3CX-servers. This is what I found...

On 23-10-2019 one 3CX server was able to transfer its back-up through FTP. The previous day that same transfer was still unsuccessful. This could indicate a change of the ProFTPd-server. However, several other clients still had failed FTP's, but over time these installations became successful and kept successful.
Another 3CX-server had its first successful transfer in November.

This means that an update of 3CX in October 2019 fixed the problem and not an update of the server.
I am sure however that it was a change on the server-side that stopped these transfers on May 7 2018. I did a Plesk update that day and all transfers then failed until 2019.
 
Back
Top