Deja Dup is unable to detect network connection

I haven't seen this myself. Can you upload /tmp/deja-dup.gsettings after running the following command?

gsettings list-recursively org.gnome.DejaDup > /tmp/deja-dup.gsettings

Her is the file :

thanks

Hmm, I thought at first that this might be some goofiness with SMB, but I just tested with an SMB server, and it seems like it works.

This is still a problem?

yes I still have the problem. Note that I 've upgraded from 11.10. I have no clue about what is giong on.

I am having the exact same problem only I have not upgraded. Started with 12.04 alpha 2. I did do a restore from an 11.10 backup.

Status changed to 'Confirmed' because the bug affects multiple users.

When you experience this, can you browse to the windows share in your File Browser?

sorry for delay but yes, I can access my nas through nautilus whereas Deja dup is unable to access it.

if I stop scheduled backup and then strt it I always get the same message : "Backup will begin when a network connection becomes available".

So I agree that this is a problem and that multiple people are affected. But I don't know how to reproduce. :( Until I can, it's difficult for me to make any progress on this.

Hi,
I was having the same problem and I found a workaround.

I am doing backups via ssh to a server running in my network. As I am using a special user on the server I added a host config in my .ssh/config file specifying the username IdentityFile and more to ease up access to the backuped data. The host is simply called "backup" but the actual hostname is different than that. Yet with ssh I am able to simply access my backup server by doing a "ssh backup" and this is also what I am using for the backup configuration in deja dup. Server name is "backup" which gives me passwordless access to the backupserver for the deja dup backup. And this also works perfectly for manual backups. However I was always getting the "Scheduled backup delayed" message for automatic schedules.
I have now simply added an entry to my /etc/hosts with the backup server IP and "backup" as hostname. Now the "Scheduled backup delayed" is gone and all is working.

Does anyone having this problem also have a special config similar to mine?

@Michael: Maybe with this you might be able to reproduce the problem on your side.

/schaze

Hello,

I have the same probleme with a Samba server. Manual backups are working fine, but not the automatic backup (same error message as in bug description). I'm on Ubuntu 12.04 LTS.

$ deja-dup --version
deja-dup 22.0

Please find dejadup.gesettings attached.

Hi,

the workaround of schaze was the solution for me.

I added in my case "192.168.10.1 nas" in /etc/hosts. Now my Deja Dup works autmaticallly in Ubuntu 12.04.

Same thing for me, the workaround is working for me too !
That should give a clue to Michael ! ;-)

I'm experiencing the same problem, as storage I'm using a SSH server, and my configuration is set up in ~/.ssh/config, so I've only set the "Server" and "Folder" fields in the "Backup" app.

Tracing this back to the code (looking at the deja-dup_22.0-0ubuntu2 source) gives me common/BackendFile.vala:

[...]
    else {
      when = _("Backup will begin when a network connection becomes available.");
      return yield Network.get().can_reach (file.get_uri ());
    }
[...]

Looking deeper into it, in common/Network.vala there's "public async bool can_reach(string url)" that will use the GIO GNetworkMonitor can_reach_async() method:

[...]
  public async bool can_reach(string url)
  {
    var mon = NetworkMonitor.get_default();
    try {
      var socket = NetworkAddress.parse_uri(url, 0);
      return yield mon.can_reach_async(socket);
[...]

The function is documented here: http://developer.gnome.org/gio/2.32/GNetworkMonitor.html#g-network-monitor-can-reach-async

The socket is determined by parse_uri: http://valadoc.org/#!api=gio-2.0/GLib.NetworkAddress.parse_uri

I'm not sure if there's an easy solution to this problem, especially since it's not enough to just parse the SSH config and check for the "right" hostname, as one could use ProxyCommand to do further indirections (I coincidentally do this, because I have to connect to different IPs depending on whether or not I'm inside or outside the private network where the backup machine is located).

Host mybackupserver
    ProxyCommand some-script-to-open-a-ssh-connection

See the ssh_config(5) manpage for more information.

I guess the easiest way to fix this would be to special-case SSH URIs and just use the "ssh" command to try to make a connection, and use that for the can_reach method - this will also take care of ProxyCommand and friends, and should be more to the point.

> I guess the easiest way to fix this would be to special-case SSH URIs and just use the
> "ssh" command to try to make a connection, and use that for the can_reach method - this
> will also take care of ProxyCommand and friends, and should be more to the point.

Since there are also errors being reported here against smb, no special casing is necessary. Just attempt to make a connection using the specified GIO method.

I have this error too.
I'm using Ubuntu One to save the files.

Is there a workaround for this case?

Have had this issue for a while and believe it started for me when updating to 12.10.
Have been mucking around a lot this morning and when making coffee it just started to work again.
Not sure what is the root cause is yet but have done the following.
I started with the theory that the fact I cannot browse via SMB to my NAS is the problem.
- I installed cifs-utils
- I edited /etc/samba/smb.conf. Here I changed the 'WORKGROUP' to a friendly name and I changed the search order to start with bcast.
- I edited /etc/nsswitch.conf to include wins
- I disabled GUFW
- I have long had this issue with Avahi (http://avahi.org/wiki/AvahiAndUnicastDotLocal). I changed the domain name here to the friendly workgroup name from smb.conf.
(These ideas from http://ubuntuforums.org/showthread.php?t=1169149)
-I have an old script that mount my NAS share via gfvs command that runs at logon. The backup now running is against one of these shares.
-I manually mounted another share via mount.cifs
- Have tried to understand the authentication issues I seem to have with SMB by following BAB1s advice looking at smbclient -d3

Somewhere in this mess lies my answer as it is now running again. I will write more when / if I find the culprit

The /etc/hosts or ~/.ssh/config workaround didn't work from me (I primarily used mDNS/Bonjour name resolution). However, I found this error report in ~/.xsession-errors:

** (deja-dup-monitor:2413): WARNING **: Network.vala:50: Error resolving '': No address associated with hostname

I'm using Ubuntu 12.04 with deja-dup 22.0.

Manual backup works, automatic doesn't. How do workflows differ from each other?

This is the culprit code from http://bazaar.launchpad.net/~deja-dup-hackers/deja-dup/22/view/head:/common/Network.vala:

public async bool can_reach(string url)
  {
    var mon = NetworkMonitor.get_default();
    try {
      var socket = NetworkAddress.parse_uri(url, 0);
      return yield mon.can_reach_async(socket);
    }
    catch (Error e) {
      warning("%s", e.message);
      return false;
    }
  }

I guess the settings from 'deja-dup-preferences' don't get parsed correctly?

One possible half-solution is to first try to mount the location. If we can do so without needing to prompt the user, we're good. Else fallback to the current code. This will catch tricky cases of SSH redirection, as long as the user has saved their SSH password.

If they haven't... I don't know of a good solution to make it work seemlessly for all SSH cases. Maybe a gsettings key could be added to disable network checking.

Had the same problem on 12.10. I back up to a Windows Share on the local network. I tried opening the share via Nautilus, but it made no difference, I still got the network connection error message. I tried schaze 's workaround and that worked for me.

In /etc/hosts I added the destination computer's IP address and share name and from then it worked automatically. I hadn't tried any other workarounds.

Perhaps the scheduled backup failures have something to do with the encryption? Just a thought as nobody mentioned it before.

I'm also affected by this bug. I use samba share with the backup encryption enabled. Both samba and backup credentials are saved in the Seahorse password storage so I don't need to t type them in.

Same here (Ubuntu 12.04.2, all updates applied). "Backup will begin when a network connection becomes available". Manual backup works after entering password for both SMB share and backup.

Here is my %gconf.xml:

<?xml version="1.0"?>
<gconf>
 <entry name="path" mtime="1371905937" type="string">
  <stringvalue>smb://Workgroup;User@mynas/User/Ubuntu-Backup</stringvalue>
 </entry>
</gconf>

I have the same problem on ubuntu 13.10

I currently change the ip of my nas server inside the .ssh/config file on a regular basis (similar to the ProxyCommand) - I've found a workaround based on the comments here, basically add the Host alias from .ssh/config to /etc/hosts (even just pointing to 127.0.0.1, this'll trick deja-dup into always believing a connection is available)

I have same problem, Ubuntu 14.04, NAS over SMB. Works fine if started manually.

Same problem here. Ubuntu 14.04.1. DejaDup never starts automaticly. The backup folder is on a harddisc at the router and perfektly reachable over smb://
Starting the DejaDup backup manualy works perfekt.

Same problem here. Ubuntu 14.10. Backup on samba share. Manual backup works ok. Adding samba host to /etc/hosts fixed it for me.

Same problem here. Ubuntu 14.10. Backup on Samba share. Just added samba host to /etc/hosts, we'll see what gives next week :)

$ uname -a
Linux DLAL0412-032 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15 22:27:29 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Same problem. Ubuntu 14.04.2 LTS.
Backup on Netgear ReadyNAS Duo as Windows Share.
Manual backup worked OK but scheduled backup delayed
Adding line to /etc/hosts fixed it.

I got this after upgrading to "mint 18 sarah" (ubuntu 16.04). Adding Nas' IP and Hostname to "hosts" file did resolve for me.

May be this relates to events logged on windows members of the same local network:

NetBT 4321: "The name "%2" could not be registered on the interface with IP address %3. The computer with the IP address %4 did not allow the name to be claimed by this computer." (Where "%2" represents the name and Id of the Workgroup, "%3" the name of the event recording client and "%4" the name of the Linux client where scheduled start of dejadup does not work when not having appropriate entry in "hosts" file

bowser 8003: "The master browser has received a server announcement from the computer "%2" that believes that it is the master browser for the domain on transport NetBT_Tcpip_{<Id>}. The master browser is stopping or an election is being forced." (Where "%2" represents the name of the Linux client where scheduled start of dejadup does not work when not having appropriate entry in "hosts" file.)

I can confirm the Bug. I try to backup using SSHFS to a remote location. SSH works fine, scp works fine, duplicity from command line works fine. Deja-dup is not able to find the backup location:

"Backup location not available
 Waiting for a network connection..."

This affects both the scheduled as well as manual backups. So I can't backup over ssh.

Adding the host to /etc/hosts did not help. Using IP Adress over hostname did not help.

Also, after closing the window, the processes "deja-dup --backup" and "deja-dup --backup --auto" keep running and have to be killed manually.

Linux 4.4.0-45-generic x86_64
Ubuntu 16.04.1 LTS
deja-dup 34.2-0ubuntu1
duplicity 0.7.06-2ubuntu2

I'm on 16.04.1 LTS and had the following error after configuring the settings in the System Settings Backup:

   "Backup location not available
    Waiting for a network connection..."

For me, the issue was with NetworkManager. After getting the above error, I went to look at the Connection Information in the systray only to get another error:

   "Error displaying connection information:No valid active connections found!"

Following: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/305606

I found that my /etc/NetworkManager/NetworkManager.conf had:

   [ifupdown]
   managed=false

so I changed it to:

   [ifupdown]
   managed=true

rebooted and now the backup works fine.

Noticed "/etc/NetworkManager/NetworkManager.conf" being set to

   [ifupdown]
   managed=false

Setting to "true" did not change anything. Network connections independently show up as expected in Network manager.

Should be fixed in master now. Thanks for the investigation and example ssh config files!

https://git.launchpad.net/deja-dup/commit/?id=76ea4c79e6e017a553b562d2258502e4fd34a452

This bug was fixed in the package deja-dup - 35.3-0ubuntu1

---------------
deja-dup (35.3-0ubuntu1) artful; urgency=medium

  * New upstream release
    - Fixes handling of some unicode filenames
    - Fixes accuracy of checking whether some servers are reachable
      (LP: #982316)
    - Fix server password dialog giving an error if you waited a while
      before logging in (LP: #1197919)
    - Add About dialog (LP: #1703797)
    - Don't start an automatic backup on a metered connection
  * debian/control:
    - Bump Standards-Version to 4.0.0, no changes
    - Bump gtk/glib dependencies

 -- Michael Terry <email address hidden> Fri, 04 Aug 2017 12:39:31 -0400