Deja Dup is unable to detect network connection

Bug #982316 reported by eric on 2012-04-15
This bug affects 45 people
Affects Status Importance Assigned to Milestone
Déjà Dup
deja-dup (Ubuntu)

Bug Description

There is a problem with network detection for scheduled backup. I get the following notification :

Scheduled backup delayed
Backup will begin when a network connection becomes available.

The network is working and manual backup is working as well.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: deja-dup 22.0-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
Uname: Linux 3.2.0-23-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu3
Architecture: amd64
Date: Sun Apr 15 15:12:36 2012
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
 PATH=(custom, no user)
SourcePackage: deja-dup
UpgradeStatus: Upgraded to precise on 2012-04-02 (13 days ago)

eric (obrowny06) wrote :
Michael Terry (mterry) wrote :

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

summary: - deja-dup is uable to detect network connection.
+ Deja Dup is unable to detect network connection
Changed in deja-dup:
status: New → Incomplete
eric (obrowny06) wrote :

Her is the file :


Michael Terry (mterry) wrote :

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?

eric (obrowny06) wrote :

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

Destain Duckert (dduckert) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in deja-dup (Ubuntu):
status: New → Confirmed
Michael Terry (mterry) wrote :

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

eric (obrowny06) wrote :

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

eric (obrowny06) wrote :

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

Michael Terry (mterry) wrote :

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.

Changed in deja-dup:
status: Incomplete → Confirmed
schaze (schaze) wrote :

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.


Kfentine (q-peyregne) wrote :


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.

zwis (zwis) wrote :


the workaround of schaze was the solution for me.

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

eric (obrowny06) wrote :

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

Thomas Perl (thp) wrote :

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:

The socket is determined by parse_uri:!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.

Mark A. Hershberger (hexmode) wrote :

> 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 ( I changed the domain name here to the friendly workgroup name from smb.conf.
(These ideas from
-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

Martin Božič (martin-bozic) wrote :

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?

Martin Božič (martin-bozic) wrote :

This is the culprit code from

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?

Michael Terry (mterry) wrote :

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.

Pablo180 (paultait22) wrote :

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.

Tomek Bury (tomek-bury) wrote :

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.

MichaelTill (debianguru) on 2013-06-10
information type: Public → Private
information type: Private → Public
Jens (jens-launchpad-net) wrote :

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"?>
 <entry name="path" mtime="1371905937" type="string">

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, this'll trick deja-dup into always believing a connection is available)

Igor (igor-kriznar) wrote :

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

jokrebel (jokrebel) wrote :

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.

Teodor Milkov (tm-del) wrote :

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

Steven (svanpoeck) wrote :

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

workshop99 (workshop99) wrote :

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.

Markus Weyermann (byro) wrote :

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.)

tz (te2et) wrote :

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

Geoff Seeley (gseeley) wrote :

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!"


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


so I changed it to:


rebooted and now the backup works fine.

Markus Weyermann (byro) wrote :

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


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

Vej (vej) on 2017-02-14
tags: added: xenial
tags: added: trusty
Changed in deja-dup (Ubuntu):
importance: Undecided → High
Vej (vej) on 2017-03-03
Changed in deja-dup:
importance: Undecided → High
Michael Terry (mterry) wrote :

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

Changed in deja-dup:
status: Confirmed → Fix Committed
Michael Terry (mterry) on 2017-08-04
Changed in deja-dup:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in deja-dup (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions