Ubuntu

Deja Dup is unable to detect network connection

Reported by eric on 2012-04-15
172
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Déjà Dup
Undecided
Unassigned
deja-dup (Ubuntu)
Undecided
Unassigned

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)
ProcEnviron:
 PATH=(custom, no user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
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 :

thanks

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 :

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

Kfentine (q-peyregne) wrote :

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.

zwis (zwis) wrote :

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.

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

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 (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

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 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?

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"?>
<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)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions