Issue BUG Plesk 18.0.77 - FTP backups no longer work

[Amauri]

It's resolved.

Can you detail what you've done to fix the issue ?

 

[Amauri]

Disabling "Use FTPS" fix the issue but there is obviously a regression on the Plesk update.

 

[manos]

It seems this happens with plesk 18.0.77 when the remote ftp server is pure-ftpd
Solution
Edit pure-ftpd config file
Put on at Broken Clients Compatibility (at firts lines it is)
restart pureftpd

 

[janpieterk]

Our setup: Plesk 18.0.77 Update #2 running on Ubuntu 20.04.6 LTS.
Backup target: FTPS provided by pure-ftpd (running in docker, stilliard/pure-ftpd - Docker Image)
We had the same problem: all FTPS backups failed since updating Plesk from 18.0.76 to 18.0.77.
The suggestion by @manos solved the problem: after adding the cli flag --brokenclientscompatibility to the docker-compose file backups work again.

 

[Jens Johansson]

Our setup: Plesk 18.0.77 Update #2 running on CloudLinux 8
Backup target: FileZilla Server 1.12.6

We have also the issue, that a backup fails with FTP error 425. The server responds "425 Unable to build data connection: TLS session of data connection not resumed." Contrary to others in this thread curl fails with the same error message. Our curl version is 7.61.1-34.el8_10.11. If we try the same command with a newer curl version 8.17 there is no error and the connection works flawlessly. Does pleskbackup use the bundled curl 8.19 from Plesk 18.0.77#2 or does it use curl from the operating system?

 

[dischneider.de]

Running Debian 11.11, after updating to Plesk 18.0.78 update 2 from 18.0.77 issuing the same problem.

Plesk UI reports an error and will not connect, the curl command line is working well.
Remote storage is vsftpd at ubuntu 20.04 LTS, "require_ssl_reuse=NO", tested with "YES" too, no difference.

Server log shows no login from plesk but from cli (timestamp).

Seems to be a problem within plesk.

 

[Evolute]

Full description:

Plesk Obsidian 18.0.77.2 (Ubuntu 20.04 x86_64, build date 2026/04/16)

Problem: FTP backups to an external FTP server (E.g. Freebox NAS) fail with the following error:

Transport error: unable to list directory: Curl error: (18) Transferred a partial file: The last FTP request: LIST: The last FTP response: 426 Data channel closed

Investigation: Using auditd, I captured the exact command that pmm-ras builds internally:

/opt/psa/admin/bin/pmm-ras --check-repository --dump-storage=ftps://user@host : port/path --use-ftp-passive-mode

When use_ftps=true is set in BackupsSettings table, pmm-ras constructs the URL with ftps:// scheme (implicit FTPS). However, the remote FTP server only supports explicit FTPS (AUTH TLS / ftpes://). The server explicitly rejects implicit FTPS.

Root cause identified: Running pmm-ras manually with ftpes:// instead of ftps:// works perfectly:

/opt/psa/admin/bin/pmm-ras --check-repository --dump-storage="ftpes://user:pass@host:port/path" --use-ftp-passive-mode → Returns <repository-check-errors/> (no errors)

Running with ftps://: → Returns Curl error: (56) Failure when receiving data from the peer

The BackupsSettings table stores the parameters separately (host, login, use_ftps, passive_mode) and pmm-ras builds the URL internally, always using ftps:// (implicit) when use_ftps=true, instead of ftpes:// (explicit).

Note: a standard curl command with --ssl flag (explicit FTPS / AUTH TLS) works perfectly to the same server.

Request: Please add support for explicit FTPS (ftpes://) in pmm-ras, or add an option in the backup storage configuration to distinguish between implicit FTPS (ftps://) and explicit FTPS (ftpes://). Many FTP servers (including consumer NAS devices) only support explicit FTPS.