Curl 18 errors during database backup

N

netsolid

Verified User
Joined
Feb 8, 2010
Messages
36
We have some problems on one server when we do a admin backup of a certain user with secure FTP. Its only when we backup the database of that account, if we skip the database theres no error. If we backup with plain FTP theres no problem.

ftp_upload.php exit code: 18
ftp_upload.php output: curl: (18) server did not report OK, got 426
curl return code: 18

Curl version 7.80.0
Directadmin: 1.63.3
Centos 8.5.2111
PHP 74
 
All tables are checked and ok. If that was the case why would normal FTP give no errors? Could it be a combination of Centos 8/curl and the backup script? All our other servers (Centos 7, Almalinux) have no problems.
 
On this server all the other accounts have no problems but a few accounts have these errors. Its a admin backup.
 
That's odd. Just to be sure, I presume you already found and read this thread?

Solved - (Explicit) FTPS not working for admin backups.

Hello everyone, I am currently trying to setup an vsFTPd backup server for 2 weeks now. For as far as i can tell it works as intended. (My FileZilla client works with that FTP server.) But it always fails when i use this FTP server for my admin backup. I always get the following message: User...
forum.directadmin.com forum.directadmin.com
it's not exactly the same but maybe you see similarities which might give you an idea about a possible cause.
 
Yes, i found that thread, but my ftp server is used by several DA servers. And the fact that only a few accounts cant backup i presume the problem is on this server.
 
Could this be a local firewall problem (on the server from where you try to upload from) or some network issue?

"The HTTP 426 Upgrade Required client error response code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an Upgrade header with this response to indicate the required protocol(s)." (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/426)

and curls return code 18 means "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." (https://curl.se/libcurl/c/libcurl-errors.html)

So it seems either the upload fails due to firewall/network issues or there's some version mismatch for ftp/http protcol.

Or maybe some antivirus software detects something in the uploaded data and thus cancels the upload for this specific accounts?
 
Almost all the accounts have no error and always the same 5 account do. If i backup one of those 5 im getting also the error. That cant be a firewall issue, firewalls are set on server level, not on account level. I know thats the error is about partial files. I also created a wait state after each account backup. That didnt help.
 
Just an odd thought maybe, because code 18 can point to expected transfer size issue....

Are these 5 accounts with the issue a lot bigger then the rest, or maybe the other way around, a lot smaller?

Could it have something to do with certain hidden folders in these accounts? Or maybe not well configured .backup_exclude_paths file (or presence of this) in those accounts?
Or for some reason some temp is included which curl sees and normal ftp doesn't care about? Just guessing possibility's here.
 
Why is a backup with plain FTP going well and with secure FTP not? i dont think its in the accounts, but i will check. thanks
 
I solved my problems after reading this article https://ixnfo.com/en/solution-clien...ontrol-channel-rejecting-data-connection.html
its saying that curl do not reuse SSL sessions. So i modified ftp_upload.php

cp -rp /usr/local/directadmin/scripts/ftp_upload.php /usr/local/directadmin/scripts/custom/ftp_upload.php

Edit the file after # FTPS and changed
${CURL} --config ${CFG} ${SSL_REQD} -k ${MIN_TLS} --silent --show-error --ftp-create-dirs --upload-file $ftp_local_file ftp://$ftp_ip:${PORT}/$ftp_path$ftp_remote_file 2>&1

to
${CURL} --config ${CFG} ${SSL_REQD} -k ${MIN_TLS} --silent --tls-max 1.2 --show-error --ftp-create-dirs --upload-file $ftp_local_file ftp://$ftp_ip:${PORT}/$ftp_path$ftp_remote_file 2>&1
 
Do you also have a solution for having the same error when listing files from on existing backup on a FTPS server? I tried hacking your fix into ftp_list.php but it didn't work out.
 
netsolid said:
I solved my problems after reading this article https://ixnfo.com/en/solution-clien...ontrol-channel-rejecting-data-connection.html
its saying that curl do not reuse SSL sessions. So i modified ftp_upload.php

cp -rp /usr/local/directadmin/scripts/ftp_upload.php /usr/local/directadmin/scripts/custom/ftp_upload.php

Edit the file after # FTPS and changed
${CURL} --config ${CFG} ${SSL_REQD} -k ${MIN_TLS} --silent --show-error --ftp-create-dirs --upload-file $ftp_local_file ftp://$ftp_ip:${PORT}/$ftp_path$ftp_remote_file 2>&1

to
${CURL} --config ${CFG} ${SSL_REQD} -k ${MIN_TLS} --silent --tls-max 1.2 --show-error --ftp-create-dirs --upload-file $ftp_local_file ftp://$ftp_ip:${PORT}/$ftp_path$ftp_remote_file 2>&1
Click to expand...
This solution worked with our AlmaLinux8 servers connecting to a different FTP server.
 
Last edited:
You must log in or register to reply here.
Back
Top