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....

 

[fliegerhermi]

Hi trialotto,

it is always the same backup location.
What's interesting about it: A full backup, that is manually started through the gui is always working.
It is really strange....

 

[trialotto]

@fliegerhermi

Most things are not strange - strange things are often the result of the wrong questions being answered or the right questions being incorrectly answered.

For instance, it can be the case that your FTP user has not been setup properly and/or that the remote backup directory has permission issues.


In this situation, I would really recommend to

1 - using an existing directory in the remote backup domain, preferably the "private" (sub-)directory (read: restricted or less accessible from the web)

2 - create a new FTP user that has the "private" (sub-)directory as "home" (landing) domain

3 - change the backup settings of one small domain in order to have backup processes use the newly created FTP user,

4 - run a full backup for that one (small) domain

5 - add an empty (test) file or a (test) file with the contents "test" to that one (small) domain

6 - run a incremental backup first,

7 - remove the test file and rerun the incremental backup : this is to check whether the incremental backup removes the test file (as it should!)

8 - create a second test file with a different name

9 - rerun a full backup and check whether the second test file is included


All of the above is basic testing, in order to determine whether the backup processes are working properly.

If the backup processes work properly, then there is - apparently - an issue with either your old FTP user setup or the old backup directory.

One can focus on the solution of the issue(s), but one is better off by simply changing to the new FTP user settings.

If the backup processes do not work properly, then there is - very likely - an issue with your FTP configuration (either remote or local) or server settings.

One can focus on the solution of FTP config / server settings related issues later ........... there probably is no need to do so.


As a final remark, whenever setting up a remote backup domain, then one should ascertain that the backup domain is not accessible from the web.

There are many elaborate solutions, but there are also some simple solutions : one can - for instance - backup to a domain that has hosting deactivated.

However, first things first, let's try to get the backup processes working without any minor or major issue!


Kind regards.....