Issue Remote SFTP-Backups fails with 425 error

[fliegerhermi]

Server operating system version

Ubuntu 24.04.3 LTS

Plesk version and microupdate number

18.0.71 #2

Unable to create the remote backup: Transport error: unable to list directory: Curl error: (18) Transferred a partial file: The last FTP request: LIST: The last FTP response: 425 Unable to build data connection: Operation not permitted

Hi everyone,

I have a problem with my remote backup for a couple of days now. The automatic backups fails with the above error every night.
When I manually start a full server backup or an incremental one to the same remote space it is working.

What can I do?
Thank you!

 

[Sebahat.hadzhi]

Hello, @fliegerhermi . Kindly try the following:

1. Connect to the Plesk server via SSH.
2. Add option to /usr/local/psa/admin/conf/panel.ini:

[pmm]
ftpMaxTlsVersion = 12

Please let us know if that helped.

 

[fliegerhermi]

Thank you for the reply.
Unfortunately that didn’t do the trick. Do you have another idea?

 

[Sebahat.hadzhi]

Thank you for the confirmation. Could you please double-check if the remote server accepts FTPS data connections in general? For example:

curl -v --ftp-ssl --ssl-reqd ftp://yourftpserver.com/ --user username:password

 

[fliegerhermi]

Yes, this is working. Also manual backups to this FTPS-Server are still working. Only the nightly automatics are failing.

* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.3 (IN), TLS alert, close notify (256):
* Remembering we are in dir ""
* TLSv1.3 (OUT), TLS alert, close notify (256):
< 226 Transfer complete
* Connection #0 to host server45.XXX.de left intact

 

[Sebahat.hadzhi]

Thanks. Can you please also run and confirm the outcome:

curl -v --ftp-ssl-control ftp://yourftpserver.com/ --user username:password

 

[fliegerhermi]

* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< 331 Password required for XXX
> PASS XXX
< 230 User XXXlogged in
> PBSZ 0
< 200 PBSZ 0 successful
> PROT C
< 534 Unwilling to accept security parameters
> PWD
< 257 "/" is the current directory
* Entry path is '/'
* Request has same path as previous transfer
> EPSV
* Connect data stream passively
* ftp_perform ends with SECONDARY: 0
< 229 Entering Extended Passive Mode (|||55025|)
* Connecting to XXX (XXX) port 55025
* Trying XXX:55025...
* Connected toXXX (XXXX) port 21
> TYPE A
< 200 Type set to A
> LIST
< 150 Opening ASCII mode data connection for file list
* Maxdownload = -1

Is a certificate required or would a self signed certificate be sufficient?

 

[fliegerhermi]

What is interesting. I get a different error message now.
While the backup isn't failing in the panel anymore I get an email with the following message:

Transport error: unable to read file /check0/test: Curl error: Unable to resume an interrupted download: (18) Transferred a partial file: The last FTP request: RETR test: The last FTP response: 150 Opening BINARY mode data connection for test (41 bytes): Connection to the FTP server has lost

The FTPS-Server Location is configured to use passive mode.

 

[trialotto]

What is interesting. I get a different error message now.
While the backup isn't failing in the panel anymore I get an email with the following message:


The FTPS-Server Location is configured to use passive mode.

@fliegerhemi,

The error message can - in theory - be safely ignored.

However, this

"150 Opening BINARY mode data connection"

is normally indicative of a firewall blocking the passive ports used for FTPS (or, in some rare cases, issues with the range of predefined passive ports).

If you allow the passive ports for FTPS, then it is very likely (but not certain) that your previous (failed) file transfer will resume.

If you have already allowed the proper passive ports, then one can safely ignore the error notification.


By the way, I am bit more worried about the

"534 Unwilling to accept security parameters"

line in the output that you provided.

It is - often - an indication of authorization issues related to (not supported) IPv6 settings.

Do you have IPv4 enabled?


Kind regards.....

 

[fliegerhermi]

Hi, thank you.
I will check the passive ports in the firewall against the ftpserver-config again.
Both servers have ipv4 and ipv6 enabled.

However this seems to be a one time error. The update is running without error messages (neither in the GUI nor through email) at the moment

 

[trialotto]

Hi, thank you.
I will check the passive ports in the firewall against the ftpserver-config again.
Both servers have ipv4 and ipv6 enabled.

However this seems to be a one time error. The update is running without error messages (neither in the GUI nor through email) at the moment

@fliegerhemi,

If you do not have the 534 error, then do not worry.

However, please check carefully when you do reconnect.

If the 534 error is present, then you might need to force FTP connections over IPv4 - otherwise, you will get authentication failures that can cause major issues.

Kind regards.....

 

[fliegerhermi]

Well here we go again. Suddenly I get the error report again. The incremental backups seem to work. Only the full ones fail

Unable to create the remote backup: Transport error: unable to list directory: Curl error: (18) Transferred a partial file: The last FTP request: LIST: The last FTP response: 425 Unable to build data connection: Operation not permitted

 

[trialotto]

Well here we go again. Suddenly I get the error report again. The incremental backups seem to work. Only the full ones fail

Unable to create the remote backup: Transport error: unable to list directory: Curl error: (18) Transferred a partial file: The last FTP request: LIST: The last FTP response: 425 Unable to build data connection: Operation not permitted

@fliegerhermi

This is an indication that your first connection (read: when backing up) is not established properly.

A distinction between incremental or full backup should not exist - if and only if config and settings (including firewall related settings) are proper, then both types of backup should exhibit either the same errors or no errors at all.

At least, that is the theory that should also exist in practice.

Do you perhaps make backups to different locations on the target server and/or to two different target servers?

It can be the case that you have permission (read: read/write) related issues with the location that is used for the full backup.

One can test this by simply using a different folder location and make a simple (small) test backup.

In addition, it can - still - be the case that your 534 error code becomes relevant.

Finally, it can be the case that you have too much processes running at once - do you run the incremental and full backups at more or less the same time?


Kind regards....