ftp failed in scheduled backup in one server

12 posts / 0 new
Last post
#1 Mon, 11/05/2012 - 09:12
humansoft

ftp failed in scheduled backup in one server

How are you?

I executed scheduled backup to B server in A server.

Ftp failed error occured.

error screen attached

https://www.virtualmin.com/system/files/vm_err01.gif

Uploading archive to FTP server pnuclimb.huso24.com .. .. upload failed! Failed to connect to 112.216.156.205:35082 : No route to host

I think the numbers attached to the following ftp address causing the error,

I do not know the reason why the number appears.

If execute backup to A server in B server, completed without error.

A server is an independent individual server, B independent individual server.

A server CentOS 5.8 webmin 1.600 virtualmin 3.94 gpl.

B server CentOS 6.3 webmin 1.600 virtualmin 3.94 gpl.

Mon, 11/05/2012 - 09:25
Locutus

The random port number could be the port used for Data connection. I don't think Virtualmin would use random port numbers for FTP without being instructed as such. :)

Is Server B behind a firewall/NAT router?

Mon, 11/05/2012 - 19:26 (Reply to #2)
humansoft

Thank you at reply.

In B server, Do not give port number to ftp address in B server.

Also, they use ftp address without using ip address.

In B server backup log

[Backup destination] /public_html/seorabulfood_202_121105 on FTP server seorabulfood.humansoft.kr

Although I will format A server by CentOS 6.3, I should like to can know the cause.

- Old man novice

Tue, 11/06/2012 - 06:17 (Reply to #3)
humansoft

Ah, yes,

Again, this time on another server, schedule backup I tried, the results are as follows.

...upload failed! Failed to connect to 112.216.156.202:59327: No route to host

I do not know the reason why a random port number is added.

I now fell into a deep despair.

- Old man novice

Tue, 11/06/2012 - 06:44
Locutus

About the random port number:

As I said, I have the suspicion that it is the DATA connection port number, which is randomly chosen according to how FTP works.

Connection to your IP and port 21 works, I just tried that.

I think you haven't answered my question stemming from the suspicion yet: Is/are your backup servers, i.e. those you're trying to connect via FTP, located behind a router/firewall? That would explain why the backup process cannot connect to the FTP DATA port.

Tue, 11/06/2012 - 07:02 (Reply to #5)
humansoft

Thank you for the answer.

There is nothing.

Each server is a stand-alone server with a fixed ip.

I do not have a router or firewall.

from my desktop pc, ftp connect without a port number, successfully connected well.

- Old man novice

Tue, 11/06/2012 - 08:08
andreychek

Can you connect from one server to the other via others means, such as SSH?

-Eric

Tue, 11/06/2012 - 19:00 (Reply to #7)
humansoft

Thank you for your interest.

I am a little confused

In schedule backup well running server, ftp: "command not found"

In server "ftp failed" on schedule backup, ftp command is running well.

copy pasted

205 server (CentOS 6.3) connecting to CentOS 5.8 server

[root@huso24 ~]# ftp 210.127.253.70

bash: ftp: command not found

[root@huso24 ~]#

70 server (CentOS 5.8) connecting to CentOS 6.3 server

[root@mail ~]# ftp 110rotc.huso24.com

Connected to 110rotc.huso24.com.

220 FTP Server ready.

500 AUTH not understood

500 AUTH not understood

KERBEROS_V4 rejected as an authentication type

Name (110rotc.huso24.com:root): pnuclimb

331 Password required for pnuclimb

Password:

230 User pnuclimb logged in

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> quit

221 Goodbye.

[root@mail ~]# ftp 112.216.156.205

Connected to 112.216.156.205.

220 FTP Server ready.

500 AUTH not understood

500 AUTH not understood

KERBEROS_V4 rejected as an authentication type

Name (112.216.156.205:root): pnuclimb

331 Password required for pnuclimb

Password:

230 User pnuclimb logged in

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> quit

221 Goodbye.

[root@mail ~]#

Here are 205 server iptables

Firewall configuration written by system-config-firewall Manual customization of this file is not recommended.

*filter

:FORWARD ACCEPT [0:0]

:INPUT ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -p udp -m udp --dport ftp-data -j ACCEPT

-A INPUT -p udp -m udp --dport ftp -j ACCEPT

-A INPUT -p udp -m udp --dport domain -j ACCEPT

-A INPUT -p tcp -m tcp --dport 20000 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT

-A INPUT -p tcp -m tcp --dport https -j ACCEPT

-A INPUT -p tcp -m tcp --dport http -j ACCEPT

-A INPUT -p tcp -m tcp --dport imaps -j ACCEPT

-A INPUT -p tcp -m tcp --dport imap -j ACCEPT

-A INPUT -p tcp -m tcp --dport pop3s -j ACCEPT

-A INPUT -p tcp -m tcp --dport pop3 -j ACCEPT

-A INPUT -p tcp -m tcp --dport ftp-data -j ACCEPT

-A INPUT -p tcp -m tcp --dport ftp -j ACCEPT

-A INPUT -p tcp -m tcp --dport domain -j ACCEPT

-A INPUT -p tcp -m tcp --dport submission -j ACCEPT

-A INPUT -p tcp -m tcp --dport smtp -j ACCEPT

-A INPUT -p tcp -m tcp --dport ssh -j ACCEPT

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -p icmp -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -p tcp -m state -m tcp --dport 22 --state NEW -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

COMMIT

Generated by webmin

*mangle

:FORWARD ACCEPT [0:0]

:INPUT ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

:PREROUTING ACCEPT [0:0]

:POSTROUTING ACCEPT [0:0]

COMMIT

Completed Generated by webmin

*nat :OUTPUT ACCEPT [0:0] :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT

Completed

- Old man novice

Fri, 11/09/2012 - 01:44 (Reply to #8)
humansoft

Thank you,

I tried a scheduled backup to a remote server, if select FTP, the upload failed!

If i select SSH, upload is successful.

I do not know why PORT number are attached in ftp connect.

Uploading archive to FTP server kua.huso.biz .. ...upload failed! Failed to connect to 112.216.156.206:32970: No route to host

- Old man novice

Fri, 11/09/2012 - 08:55
andreychek

Well, SSH is a more secure way of transferring the backups, I'd highly recommend that, even if you weren't having problems.

However, if you're hoping to use FTP -- you might consider temporarily disabling the firewall on the remote host, just to see if the transfer is successful at that point.

-Eric

Fri, 11/09/2012 - 22:32
humansoft

Thank you very much.

I decided to use ssh.

It works very well.

- Old man novice

Sat, 11/10/2012 - 03:17
Locutus

I agree with Eric! FTP transmits passwords unencrypted, so if at all possible, SSH is preferable.

Topic locked