Getting "Error while running [backup]: No route to host"

Support
1

Hi,

First I would like to thank the developers for a great product. Keep up the good work :slight_smile:

I’m experiencing an error in Duplicati, and hope someone can help me get it sorted.

I have a 2.0.5.1 BETA Duplicati Linux instance running a SFTP backup via tray, which have been running to a remote storage without errors in a years time. Yesterday I got a “Warning: No route to host”, and the backup stops after “veryfing romote host” without running the backup.

The log in “About / Logs”:

System.Net.Sockets.SocketException (0x80004005): No route to host

Followed by a longer text which I think is related to the above error. Let me know if the longer log is needed to troubleshoot.

I’v tried:

  • To connect to the remote storage via a FTP client and the terminal, which works fine
  • Searched the Duplicati forums without any luck. Some threads have the System.Net.Sockets.SocketException (0x80004005) part, but not combined with the No route to host part.

Any help would be very much appreciated.

2

Hello and welcome!

Does this error also occur when you test the connection? Edit the backup job, go to the Destination page, and click the Test Connection button. If it does, double check the destination hostname you entered on this page.

1 Like
3

Hello and thanks!

And thanks for the advice. I have tested the connection at the Destinations page as you suggest, and get the error: Failed to connect: No route to host. So not the longer warning, but seems to be the same error as mentioned.

I have double checked the destination, user and password. And as described used the same information as in Duplicati to make successful logins to the destination storage in a FTP client and in the commandline.

AFAIK neither the supplier or I have changed the destination, user, path or password - and it have worked for a year without any hickups.

4

“No route to host” is not a user/password issue, but more fundamental than that. Duplicati can’t reach the destination at all.

On the same Linux machine that runs Duplicati, try opening a shell and pinging the destination host.

1 Like
5

Tried pinging the destination host and got 100% packet loss and: Destination unreachable: Address unreachable.
Huh… So I can connect to the destination with a FTP client and in the terminal - but can’t ping it or connect to it with Duplicati.

6

Ping confirms there is something lower level that is wrong. To be clear are you running the FTP client test on that same machine that Duplicati runs on? I would expect it to also fail if that were the case.

7

Both the FTP client and the terminal connected to the storage from the same machine that Duplicati runs on.

8

Is Duplicati running natively on the host, or in a Docker container?

9

It’s running on the host - a Ubuntu 18.04 box.

10

This sounds like you have a firewall between you and the host blocking ICMP and TCP port 22.
Are you able to SSH into the host from other locations?

11

I’ve been wondering what terminal program you use that does SFTP. Or do you mean you ran sftp client?

Were there any known changes to Duplicati or anything else that might have led to the changed behavior? Earlier there was mention of some things believed unchanged, but it wasn’t very long. Just fishing more…

Is this a basic home setup, or is there a VPN or company network environment the data must go through?

Long logs can help. In addition to more lines, logs to file can capture what part of the code made the lines.
log-file=<path> and log-file-log-level=warning to watch the Test connection would be good, but easier is About → Show log → Live → Warning, and easier still is to post whatever detailed log info you already got.

There’s no guarantee the longer log will help, but it might.

Approaching it from a different angle, you could Export As Command-line to get target URL then try using Duplicati.CommandLine.BackendTool.exe to run a list, which is usually all that Test connection tests.

Do ping -4 versus ping -6 behave differently? You can also look at address in your default ping output.
IPv4 would announce a PING to an address with four decimal numbers. IPv6 would be a much longer one. Interestingly, “Address unreachable” doesn’t appear to exist in IPv4 ICMP, and might imply IPv6 was used.

The ping source suggests an ICMPv6 response returned, from the format the error message printed out.

Applications might vary in how they decide which IP version to use. You can use your ping test to find the address, and try having the applications use it. Possibly that will provide more consistency between them.

2 Likes
12

Maybe. But if that is the case, I don’t think I would be able to connect to the storage at all, which I can from the same machine using 1) SFTP in the terminal and 2) a FTP client with the same credentials as in Duplicati.

1 Like
13

Thanks all for your great input and advice! Thanks to you it’s up and running again! :smiley:

Solution

What I did
Ping -4 connected while ping and ping -6 didn’t. So I changed the destination address in Duplicati from an URL to the IPV4 IP address, and then Duplicati could connect without errors / warnings.

Possible causes of the warning “Error while running [backup]: No route to host”]
As I said Duplicaiti have been running fine in a years time with the URL as the destination address, and I could connect with the URL in sftp (terminal) and a GUI FTP client just fine. My best bet is that the error was caused by one of the following:

  1. A change in the host nic settings, which made Duplicati use the IPV6 address
  2. A change at my DNS provider, which made Duplicati use the IPV6 address
  3. A change at my storageprovider, which made Duplicati use the IPV6 address
  4. A change in Duplicati, which made it use the IPV6 address

Please add to it or correct me, if I’m wrong :slight_smile:

2 Likes
14

Glad it got figured out! Wouldn’t have guessed it was trying to use IPv6.