Curl 7.73.0

Well without much detail can't really know where to lead you. Questions that come to mind are?

Did you only update Curl?
Have you rebuilt Proftpd or PureFtpd?
OS and Version?
Have you updated the OS?
have you updated CB2?
Have you run ./build all
Have you checked
Did you copy ftp_upload.php to a custom location when you switched to curl?

Did you read this section?

I did update Curl, Custombuild is up to date. I also did run yum update and rebuild PureFTP.

DirectAdmin 1.61.5, pure-ftpd 1.0.49, CentOS 7.0 64-Bit

Update: also tested it with Curl & ProFTPd. Same results.
 
Last edited:
we are talking about pushing directadmin backups to a ftps server. it has nothing to do about directadmin's ftp server, i reckon???. it is curl or our ftps confg which was working two days ago from incident
 
We had also the same problem. And we found the reason.
Problem is in /usr/local/directadmin/scripts/ftp_upload.php

On line 23 and 25 it uses the command 'curl --help', as of version 7.73 you need to specify a help category, so the correct command need to be 'curl --help tls' (or 'curl --help all')

(same problem in ftp_list.php)
 
Last edited:
We had also the same problem. And we found the reason.
Problem is in /usr/local/directadmin/scripts/ftp_upload.php

On line 23 and 25 it uses the command 'curl --help', as of version 7.73 you need to specify a help category, so the correct command need to be 'curl --help tls' (or 'curl --help all')

(same problem in ftp_list.php)
It's been fixed in pre-release, thank you for the report in the ticketing!
 
Found this topic through search. Can confirm FTPS-backups stopped working after I updated Custombuild and thus Curl past monday.
The error message in the ticket system looks like this:

Code:
ftp_upload.php exit code: 67
ftp_upload.php output: curl: (67) Access denied: 504
curl return code: 67
 <2:33:15>
Please see this URL and check for curl exit code '(67)': https://help.directadmin.com/item.php?id=2127
 
Found this topic through search. Can confirm FTPS-backups stopped working after I updated Custombuild and thus Curl past monday.
The error message in the ticket system looks like this:

Code:
ftp_upload.php exit code: 67
ftp_upload.php output: curl: (67) Access denied: 504
curl return code: 67
<2:33:15>
Please see this URL and check for curl exit code '(67)': https://help.directadmin.com/item.php?id=2127
Just update to pre-release and you should be fine.
 
Hello Martynas,

Just wanted to bump this one. It seems not to be in the stable release as of yet. Has been four months now.

Kind regards,

Richard
 
Yes still the same for me.

Code:
/usr/local/bin/curl returned error code 67
curl: (67) Access denied: 504
FTP information invalid.

I'm on the latest custombuild version. I only use stable release.

How to fix this please?
 
We had also the same problem. And we found the reason.
Problem is in /usr/local/directadmin/scripts/ftp_upload.php

On line 23 and 25 it uses the command 'curl --help', as of version 7.73 you need to specify a help category, so the correct command need to be 'curl --help tls' (or 'curl --help all')

(same problem in ftp_list.php)
@Tazmanian79 this should contain all the info to fix it yourself. But of course after an update changes will be gone again. That is why it would be very nice to have this minor improvement in the stable release. @smtalk any idea on when this would be done?
 
Did this bug just return?

Had the exact same issue as before on a newly spawned and fully updated VPS. Following these steps fixed the issue and gave me remote admin backup access again.
 
Did this bug just return?

Had the exact same issue as before on a newly spawned and fully updated VPS. Following these steps fixed the issue and gave me remote admin backup access again.
It did not return, it's just still not fixed.
 
This is now finally fixed with DirectAdmin 1.62.0 (for me at least).
Well, I had no problems, till I updated to the latest DirectAdmin version:

Code:
ftp_upload.php exit code: 18
ftp_upload.php output: curl: (18) server did not report OK, got 426
curl return code: 18
 
We're still having similar issues:

Error with getFtpFile:
/usr/bin/curl returned error code 28
curl: (28) Timeout was reached

Can confirm that we're not blocked as we're able to telnet via port 21.
 
Back
Top