ftp_upload.php output: curl: (18) server did not report OK, got 451

alrnetwork

Verified User
Joined
Feb 12, 2021
Messages
166
Location
Europe UTC+2
Hi there,

Attempting to perform secure FTP backups from one DA server to another, results in the following error message:

Code:
 <20:19:23>
Please see this URL and check for curl exit code '(18)': https://help.directadmin.com/item.php?id=2127
User hidden has been backed up. <20:19:37>
ftp_upload.php exit code: 18
ftp_upload.php output: curl: (18) server did not report OK, got 451
curl return code: 18

  • Both servers are running the latest version of DirectAdmin
  • Both FTP users have been tested and confirmed as working
  • Both servers are running CSF and have each other whitelisted
  • Port 21 and 22 are open

Not sure what's going on here. Please can you advise?
 
Anyone have any suggestions? Ideally, I'd like to keep Secure FTP enabled. Just something to add, it appears that the backups are sent across with no problem.. just a bad response.
 
I'm having the same problem. System is RHEL 8.4. File uploads fine but gets error.

User admin has been backed up. <5:01:01>
ftp_upload.php exit code: 18
ftp_upload.php output: curl: (18) server did not report OK, got 451
curl return code: 18
<5:01:02>
Please see this URL and check for curl exit code '(18)': https://help.directadmin.com/item.php?id=2127
User user1 has been backed up. <5:01:26>
User user2 has been backed up. <5:01:39>
ftp_upload.php exit code: 18
ftp_upload.php output: curl: (18) server did not report OK, got 451
curl return code: 18
<5:01:42>
Please see this URL and check for curl exit code '(18)': https://help.directadmin.com/item.php?id=2127

Although a backup error has occurred, the upload of valid backups would have still been attempted to ftps://someaddress/admin_backups/2021-08-23 <5:01:42>

Maybe someone here has a solution to get rid of the error?
 
User acarosgb has been backed up. <20:04:04>
ftp_upload.php exit code: 8
ftp_upload.php output: curl: (8) Failed to connect to u274090.your-storagebox.de port 21: Connection refused
curl return code: 8
<20:04:05>
Please see this URL and check for curl exit code '(8)': https://help.directadmin.com/item.php?id=2127

Although a backup error has occurred, the upload of valid backups would have still been attempted to ftp://u274090.your-storagebox.de/ <20:04:05>

I am getting the same error as above. I cannot connect to the backup server and transfer site backups from DA. Ports 20 - 21 are open. Heriey can't connect to normal ma somehow.
 
The issue only presents itself when SSL is enabled. There's nowhere to change the port in the DA interface, so I feel that whatever this issue is, needs to be rolled out as a fix in an update.
 
Hi there,

Attempting to perform secure FTP backups from one DA server to another, results in the following error message:

Code:
 <20:19:23>
Please see this URL and check for curl exit code '(18)': https://help.directadmin.com/item.php?id=2127
User hidden has been backed up. <20:19:37>
ftp_upload.php exit code: 18
ftp_upload.php output: curl: (18) server did not report OK, got 451
curl return code: 18

  • Both servers are running the latest version of DirectAdmin
  • Both FTP users have been tested and confirmed as working
  • Both servers are running CSF and have each other whitelisted
  • Port 21 and 22 are open

Not sure what's going on here. Please can you advise?
I have 100% exactly the same problem (error) The only difference is that both servers have different operating systems. Ubuntu 10 and CentOS 8(DA 1.63.0 on 64-bit) at first glance, the backups were successful. There is an archive, there is about the right size. But I did not check in practice whether it is 100% working.
 
I'm seeing the same thing. Seems like the backup is working, but the error is deceiving. It worked fine when I was backing up to my previous FTP server, but I spun up a new server, with directadmin, and now i'm getting this error. AlmaLinux on both.
 
curl exit code '(18)'
CURLE_PARTIAL_FILE (18)

A file transfer was shorter or larger than expected. This happens when the server first reports an expected transfer size, and then delivers data that does not match the previously given size.

Could be the data is changing on the disk. Not sure though.

Please see this URL and check for curl exit code '(8)'
CURLE_WEIRD_SERVER_REPLY (8)

The server sent data libcurl could not parse. This error code was known as as CURLE_FTP_WEIRD_SERVER_REPLY before 7.51.0.

CURLE_FTP_WEIRD_SERVER_REPLY (8) After connecting to a FTP server, libcurl expects to get a certain reply back. This error code implies that it got a strange or bad reply. The given remote server is probably not an OK FTP server.

You might need a update of curl or maybe you are using both the OS curl lib and the CB installed Curl Lib. or something is wrong with the remote ftp server.

You all might read through this are well. If you haven't solved it.
 
Last edited:
not everything is so simple,
For sure. A lot of people have trouble doing this way. its one of the reasons we have a feed back on the backup system.
You might vote for it so they will improve it

 
bdacus01
in fact, it is not difficult for me to vote;) but that vote is unfortunately not related to this error. It must be decided at the developer level. We hope that they will pay attention to this topic.
 
Oh, really, it's a mistake, Ubuntu and Debian for me are like brother and sister. Really install Debian 10 :cool:
Thank You! bdacus01

p.s.
unfortunately it does not fix my first post :(
 
Ubuntu and Debian for me are like brother and sister
Debian = Father
Ubuntu = Bad step child.. LOL

Ok I was worried there glad its Debian 10.

Stay safe and good luck with your developer.
 
Hello, I'm having the same error.
Did one of you solved this?

Can it be due to the usage of zst instead of tar.gz?
 
I have that problem too... but! In last 7 days once it was "succesful" so... I don't know why 95% times is that error.
 
Hi guys,

Just to let you know that I was facing the same problem and after some investigations found out that my remote backup disk partition was full.

The problem was fixed after making some free space.

Hope that helps.
 
Back
Top