deja-dup fails to backup using SFTP/SSH if Gnome Keyring is not available

[Matthias Andree]

I have had a working deja-dup setup under Ubuntu 12.04LTS. I upgraded to Ubuntu 14.04LTS. Now deja-dup no-longer works, the window states "Permission denied" (the German translation), also if I run "DEJA_DUP_DEBUG=1 deja-dup --backup" there is no output at all. (I am currently trying running it from a KDE desktop.)

I can still successfully run "duplicity collection-status" + the URL I find in org.gnome.deja-dup's file backend configuration and get a reasonable output, so it does not appear to be an ssh-related issue.

I moved .cache/deja-dup out of the way, for no improvement.

How do we go about debugging this?

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: deja-dup 30.0-0ubuntu4
ProcVersionSignature: Ubuntu 3.13.0-35.62-generic 3.13.11.6
Uname: Linux 3.13.0-35-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.4
Architecture: amd64
CurrentDesktop: KDE
Date: Wed Sep 17 08:51:40 2014
SourcePackage: deja-dup
UpgradeStatus: Upgraded to trusty on 2014-08-29 (18 days ago)

[Matthias Andree (matthias-andree)]

Actually the error message is "Access denied." - which is not very specific.

Also, the fault might be specific to running deja-dup under a KDE desktop.
Running under GNOME Flashback, I see the gcr-prompter password prompt... (from the gcr package, GNOME crypto services).

[Matthias Andree (matthias-andree)]

And there we go, the workaround seems to be running these commands in sequence from the same Konsole terminal in order shown:

eval $(/usr/bin/gnome-keyring-daemon --start --components=ssh)
export SSH_AUTH_SOCK GNOME_KEYRING_CONTROL
deja-dup --backup

[Matthias Andree (matthias-andree)]

(I should say that I am using the file backend with an sftp:// path)

[Matthias Andree (matthias-andree)]

So, bottom line is that:
1. deja-dup is failing to procure the necessary SSH/SFTP password,
2. failing to report the fact it does not have the SSH/SFTP password,
3. not offering an alternative way of getting the password (it is in my ssh-agent but still...)
4. failing to properly report which access in particular was denied, and what deja-dup was trying to do.

Keeping the UI simple is one thing, but not reporting errors in a useful way is not a useful simplification :-)

[Launchpad Janitor (janitor)]

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

[Theresa (theresa)]

any update on this issue?

[Michael Terry (mterry)]

For our own passphrases, etc, we just use libsecrets, which is not tied to a specific desktop.

But for network server access, we do rely on gvfs, which is not likely to change. And that might have some wonkiness in other desktop envs (though hopefully that’s better in 2019 than in past, assuming that it also uses libsecret now).

I’ll close this, but please reopen if you think there’s something more Deja Dup should be doing itself here.