DA-server backup/restore to/from FTP

[BeeBee]

I have several DA-servers on VPS's and two days ago I ordered a new one.
All works fine, as usual. I use them pretty straightforward.
Updated the core, directadmin and custombuild.

There is a problem however with the backup on this new one.
When I try to make a backup to a FTP-server (filezilla server), or when I try to restore something from the same FTP-server I receive errors like this:
Error with getFtpFile:
/usr/bin/curl returned error code 7
curl: (7) Failed to connect to backupda.bbit.nl port 21: Connection refused

The connection however is NOT refused. On the FTP-server I see the login goes well, I see the CWD to the right directory. But when you expect a STORE command, nothing happens and the next thing I see is "Session ended gracefully". See below the log.

<Date/Time> Info [Type] Message
<16-6-2026 16:45:40> FTP Session 142 149.xxx. [Response] 220-FileZilla Server 1.12.6
<16-6-2026 16:45:40> FTP Session 142 149.xxx. [Response] 220 Please visit https://filezilla-project.org/
<16-6-2026 16:45:40> FTP Session 142 149.xxx. [Command] USER bckup
<16-6-2026 16:45:40> FTP Session 142 149.xxx. [Response] 331 Please, specify the password.
<16-6-2026 16:45:40> FTP Session 142 149.xxx. [Command] PASS ****
<16-6-2026 16:45:40> FTP Session 142 149.xxx. [Response] 230 Login successful.
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Command] PWD
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Response] 257 "/" is current directory.
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Command] CWD /
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Response] 250 CWD command successful
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Command] CWD vps052
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Response] 250 CWD command successful
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Command] CWD Jun
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Response] 250 CWD command successful
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Command] EPSV
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Response] 229 Entering Extended Passive Mode (|||58004|)
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Command] PASV
<16-6-2026 16:45:40> FTP Session 142 149.xxx. bckup [Response] 227 Entering Passive Mode (xxx,xxx,xxx,xxx,216,141)
<16-6-2026 16:45:40> FTP Server [Status] Session 142 ended gracefully.

So no backup is stored on the FTP-server.
Other DA-servers store their backups on this same FTP-server without any problem.
When I make an admin backup to the server itself and send it via cURL to this FTP-server there is no problem at all.

The same errors happen when I try to make the backup to one of the other DA-servers by FTP.
I have a feeling it has nothing to do with FTP itself, but with a missing backup-file, or a wrong FTP-command.

Anyone who can help me with this problem? I'd appreciate it!

Cheers,
Berend.

 

[Richard G]

The connection however is NOT refused.

It still might be refused. The curl error points to more than the initial connection.
It can also point out that at a certain point, a connection is refused to a different port. And that can be a valid notice if you are (as I can see) using Passive mode.
Passive mode is not working on port 21 but on different ports. The firewall of the sending machine must be able to match those of the receiving machine.

Normally, for DA the passive portrange is 35000:35999 and in your case I see 58004 (if that is a passive port).
I presume the port range of the receiving server is open in the DA firewall, but question is if DA will indeed use these ports or at a certain point fall back to the original ports.

However, this should be fairly easy to find out if this is the case.
On the new VPS, be sure firewalld is not running and do a csf -x to disable CSF completely.
Then issue the IPTABLES -L command to see if all 3 are set to ACCEPT.

Then try the backup again. If it then works, then you know it's a firewall issue on the sending side.

Ofcourse if not you could also try this later with the receiving server.

P.s. I hope port 21 is also still open (and port 20).