Bug 795124

Summary:	Deja-dup keeps asking for encryption password
Product:	[Fedora] Fedora	Reporter:	seventhguardian
Component:	deja-dup	Assignee:	Rahul Sundaram <metherid>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	16	CC:	fedorabugmail, fedora, jitesh.1337, metherid, mike
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-24 22:21:21 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description seventhguardian 2012-02-19 14:09:44 UTC

Description of problem:

I've been using dejadup to perform regular backups of my home directory. The backups are password encrypted.

Today I noticed that dejadup is stuck in the "Encryption Password Needed" screen. I've entered the correct password, still it won't perform the backup. I suspect it won't restore the existing backups either.


Version-Release number of selected component (if applicable):
deja-dup-20.1-1.fc16
duplicity-0.6.17-1.fc16

Steps to Reproduce:
1. Run $ deja-dup --backup
2. Enter the correct password
  
Actual results:
After some seconds the password prompt will appear again

Expected results:
The backup should start.

Additional info:

The first time I ran deja-dup today, I noticed that the gid/uid for my owned directories on the backup disk were wrong (set to 500:500 instead of renato:renato). The root owned directories were correctly set to root:root. I've corrected my ownership on the affected directories.

Comment 1 seventhguardian 2012-02-24 21:38:34 UTC

I believe I found the problem. Please take note the debug command and the output:

** (deja-dup:12685): DEBUG: DuplicityInstance.vala:196: Running the following duplicity (12700) command: duplicity 'collection-status' '--exclude=/media/Renato2/backups-dejadup' '--exclude=/home/renato/.local/share/Trash' '--exclude=/home/renato/.xsession-errors' '--exclude=/home/renato/.thumbnails' '--exclude=/home/renato/.gvfs' '--exclude=/home/renato/.adobe/Flash_Player/AssetCache' '--exclude=/home/renato/.cache/deja-dup' '--exclude=/home/renato/.cache' '--include=/home/renato' '--exclude=/sys' '--exclude=/proc' '--exclude=/tmp' '--exclude=**' '--gio' 'file:///media/Renato2/backups-dejadup' '--verbosity=9' '--gpg-options=--no-use-agent' '--archive-dir=/home/renato/.cache/deja-dup' '--log-fd=14'

** (deja-dup:12685): DEBUG: DuplicityInstance.vala:568: duplicity (12700) exited with value 0

** (deja-dup:12685): DEBUG: DuplicityInstance.vala:196: Running the following duplicity (12704) command: duplicity '--exclude=/media/Renato2/backups-dejadup' '--exclude=/home/renato/.local/share/Trash' '--exclude=/home/renato/.xsession-errors' '--exclude=/home/renato/.thumbnails' '--exclude=/home/renato/.gvfs' '--exclude=/home/renato/.adobe/Flash_Player/AssetCache' '--exclude=/home/renato/.cache/deja-dup' '--exclude=/home/renato/.cache' '--include=/home/renato' '--exclude=/sys' '--exclude=/proc' '--exclude=/tmp' '--exclude=**' '--dry-run' '--gio' '--volsize=50' '/' 'file:///media/Renato2/backups-dejadup' '--verbosity=9' '--gpg-options=--no-use-agent' '--archive-dir=/home/renato/.cache/deja-dup' '--log-fd=18'

** (deja-dup:12685): DEBUG: DuplicityInstance.vala:571: duplicity (12704) process killed


The first command succeeds ('collection status') succeeds, but the second one doesnt. Running the command myself (removing the "--log-fd" part) I get this:

(...)

GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: bad key
===== End GnuPG log =====

I believe this is a red herring. The duplicity command specifies '/' as the backup directory.

I attempted to run the command again, removing any --exclude that is outside of my home directory, and replacing '/' by '/home/renato'. It worked perfectly.

Just to make sure I had the correct password, I attempted to use an incorrect one, and if failed as expected.

Comment 2 seventhguardian 2012-02-24 21:49:48 UTC

Please disregard my last comment, I was doing a backup to a different directory when it "worked perfectly".

Comment 3 seventhguardian 2012-02-24 22:21:21 UTC

I attempted to do a new test backup/verify using just duplicity (it worked).

I'm assuming this is the (unlikely but possible) case of a lost password. Closing the report.

Comment 4 James 2012-07-28 00:16:47 UTC

I've seen this behavior 3 times on F16/F17. deja-dup runs fine for several weeks then suddenly wants a password but refuses the one I give it. The only workaround I have now is to change the backup path whenever this problem arises.