Duplicity restore failing: No secret key











up vote
4
down vote

favorite
2












I'm setting up a backup from a local machine to a remote server.

I generated gpg keys on the local machine and ran a test backup with:



PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path


The backup seems to work fine, three files are created on the server.



My problem is I can't get the restore to work.

I deleted the test file on the local machine and try to restore it with:



PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test


I get the following error:



Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11
"Name <email>"
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key
===== End GnuPG log =====


I exported the gpg keys on the local machine with:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key



And imported them on the server with:
gpg --import secret.key
gpg --import public.key



Is there anything else that needs to be done for the restore to work?



Edit:

If I execute the command without the PASSPHRASE env duplicity --encrypt-key Key D test scp://user@host/path the backup is created anyway without asking for the passphrase.



Output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.










share|improve this question
























  • Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
    – Jens Erat
    Oct 11 '15 at 8:32










  • There is only one user (root) on the remote machine.
    – Pabi
    Oct 11 '15 at 11:10










  • Could be related to this. In short: Somehow gpg fails to ask for the passphrase.
    – Daniel B
    Oct 11 '15 at 12:17















up vote
4
down vote

favorite
2












I'm setting up a backup from a local machine to a remote server.

I generated gpg keys on the local machine and ran a test backup with:



PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path


The backup seems to work fine, three files are created on the server.



My problem is I can't get the restore to work.

I deleted the test file on the local machine and try to restore it with:



PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test


I get the following error:



Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11
"Name <email>"
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key
===== End GnuPG log =====


I exported the gpg keys on the local machine with:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key



And imported them on the server with:
gpg --import secret.key
gpg --import public.key



Is there anything else that needs to be done for the restore to work?



Edit:

If I execute the command without the PASSPHRASE env duplicity --encrypt-key Key D test scp://user@host/path the backup is created anyway without asking for the passphrase.



Output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.










share|improve this question
























  • Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
    – Jens Erat
    Oct 11 '15 at 8:32










  • There is only one user (root) on the remote machine.
    – Pabi
    Oct 11 '15 at 11:10










  • Could be related to this. In short: Somehow gpg fails to ask for the passphrase.
    – Daniel B
    Oct 11 '15 at 12:17













up vote
4
down vote

favorite
2









up vote
4
down vote

favorite
2






2





I'm setting up a backup from a local machine to a remote server.

I generated gpg keys on the local machine and ran a test backup with:



PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path


The backup seems to work fine, three files are created on the server.



My problem is I can't get the restore to work.

I deleted the test file on the local machine and try to restore it with:



PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test


I get the following error:



Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11
"Name <email>"
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key
===== End GnuPG log =====


I exported the gpg keys on the local machine with:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key



And imported them on the server with:
gpg --import secret.key
gpg --import public.key



Is there anything else that needs to be done for the restore to work?



Edit:

If I execute the command without the PASSPHRASE env duplicity --encrypt-key Key D test scp://user@host/path the backup is created anyway without asking for the passphrase.



Output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.










share|improve this question















I'm setting up a backup from a local machine to a remote server.

I generated gpg keys on the local machine and ran a test backup with:



PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path


The backup seems to work fine, three files are created on the server.



My problem is I can't get the restore to work.

I deleted the test file on the local machine and try to restore it with:



PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test


I get the following error:



Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11
"Name <email>"
gpg: public key decryption failed: Inappropriate ioctl for device
gpg: decryption failed: No secret key
===== End GnuPG log =====


I exported the gpg keys on the local machine with:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key



And imported them on the server with:
gpg --import secret.key
gpg --import public.key



Is there anything else that needs to be done for the restore to work?



Edit:

If I execute the command without the PASSPHRASE env duplicity --encrypt-key Key D test scp://user@host/path the backup is created anyway without asking for the passphrase.



Output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.







backup encryption gnupg duplicity






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 11 '15 at 12:09

























asked Oct 11 '15 at 2:00









Pabi

16119




16119












  • Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
    – Jens Erat
    Oct 11 '15 at 8:32










  • There is only one user (root) on the remote machine.
    – Pabi
    Oct 11 '15 at 11:10










  • Could be related to this. In short: Somehow gpg fails to ask for the passphrase.
    – Daniel B
    Oct 11 '15 at 12:17


















  • Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
    – Jens Erat
    Oct 11 '15 at 8:32










  • There is only one user (root) on the remote machine.
    – Pabi
    Oct 11 '15 at 11:10










  • Could be related to this. In short: Somehow gpg fails to ask for the passphrase.
    – Daniel B
    Oct 11 '15 at 12:17
















Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
– Jens Erat
Oct 11 '15 at 8:32




Are you sure you imported the keys to the correct user? GnuPG uses per-user key chains, services often use some system user with it's own key ring instead.
– Jens Erat
Oct 11 '15 at 8:32












There is only one user (root) on the remote machine.
– Pabi
Oct 11 '15 at 11:10




There is only one user (root) on the remote machine.
– Pabi
Oct 11 '15 at 11:10












Could be related to this. In short: Somehow gpg fails to ask for the passphrase.
– Daniel B
Oct 11 '15 at 12:17




Could be related to this. In short: Somehow gpg fails to ask for the passphrase.
– Daniel B
Oct 11 '15 at 12:17










3 Answers
3






active

oldest

votes

















up vote
3
down vote



accepted










The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.

The gpg agents needs to be enabled and configured for the restore to work.



Add the following to ~/.gnupg/gpg.conf:



use-agent
pinentry-mode loopback


And to your ~/gnupg/gpg-agent.conf:



pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry


Then restart the agent with echo RELOADAGENT | gpg-connect-agent.



The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.






share|improve this answer

















  • 2




    The second filepath is missing the dot. It should be ~/.gnupg/gpg-agent.conf (same directory as the previously mentioned file).
    – Sam
    Oct 23 at 10:40


















up vote
1
down vote













Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html



Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.






share|improve this answer























  • I am using gpg 2.1.8. If I run it without the passphrase env: duplicity --encrypt-key KeyID test scp://user@host/path it does not ask for the passphrase but the backup is created anyway.
    – Pabi
    Oct 11 '15 at 11:59










  • After doing that the output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
    – Pabi
    Oct 11 '15 at 12:09




















up vote
1
down vote













I have had this issue when using sudo to execute duplicity, which makes it search for the private key into root's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.



The most simple solution to this problem was to avoid using sudo, in my case, by setting the correct permissions on the destination directory.



If sudo is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg" to the duplicity command, as stated on this answer



Maybe this helps someone else :-)






share|improve this answer























  • So how did you resolve exactly?
    – Pimp Juice IT
    Jul 18 '17 at 19:21






  • 1




    D'oh. Added to the answer. Thanks for pointing it out.
    – Pablo
    Jul 18 '17 at 20:19











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f984977%2fduplicity-restore-failing-no-secret-key%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
3
down vote



accepted










The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.

The gpg agents needs to be enabled and configured for the restore to work.



Add the following to ~/.gnupg/gpg.conf:



use-agent
pinentry-mode loopback


And to your ~/gnupg/gpg-agent.conf:



pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry


Then restart the agent with echo RELOADAGENT | gpg-connect-agent.



The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.






share|improve this answer

















  • 2




    The second filepath is missing the dot. It should be ~/.gnupg/gpg-agent.conf (same directory as the previously mentioned file).
    – Sam
    Oct 23 at 10:40















up vote
3
down vote



accepted










The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.

The gpg agents needs to be enabled and configured for the restore to work.



Add the following to ~/.gnupg/gpg.conf:



use-agent
pinentry-mode loopback


And to your ~/gnupg/gpg-agent.conf:



pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry


Then restart the agent with echo RELOADAGENT | gpg-connect-agent.



The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.






share|improve this answer

















  • 2




    The second filepath is missing the dot. It should be ~/.gnupg/gpg-agent.conf (same directory as the previously mentioned file).
    – Sam
    Oct 23 at 10:40













up vote
3
down vote



accepted







up vote
3
down vote



accepted






The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.

The gpg agents needs to be enabled and configured for the restore to work.



Add the following to ~/.gnupg/gpg.conf:



use-agent
pinentry-mode loopback


And to your ~/gnupg/gpg-agent.conf:



pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry


Then restart the agent with echo RELOADAGENT | gpg-connect-agent.



The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.






share|improve this answer












The problem is, like the link ede posted stated, that gpg 2.1 retires passphrase from pipe for key auth.

The gpg agents needs to be enabled and configured for the restore to work.



Add the following to ~/.gnupg/gpg.conf:



use-agent
pinentry-mode loopback


And to your ~/gnupg/gpg-agent.conf:



pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry


Then restart the agent with echo RELOADAGENT | gpg-connect-agent.



The restore work even if the keys are only on the local machine.
I still dont get why it does not ask for the passphrase when making incremental though.







share|improve this answer












share|improve this answer



share|improve this answer










answered Oct 11 '15 at 14:11









Pabi

16119




16119








  • 2




    The second filepath is missing the dot. It should be ~/.gnupg/gpg-agent.conf (same directory as the previously mentioned file).
    – Sam
    Oct 23 at 10:40














  • 2




    The second filepath is missing the dot. It should be ~/.gnupg/gpg-agent.conf (same directory as the previously mentioned file).
    – Sam
    Oct 23 at 10:40








2




2




The second filepath is missing the dot. It should be ~/.gnupg/gpg-agent.conf (same directory as the previously mentioned file).
– Sam
Oct 23 at 10:40




The second filepath is missing the dot. It should be ~/.gnupg/gpg-agent.conf (same directory as the previously mentioned file).
– Sam
Oct 23 at 10:40












up vote
1
down vote













Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html



Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.






share|improve this answer























  • I am using gpg 2.1.8. If I run it without the passphrase env: duplicity --encrypt-key KeyID test scp://user@host/path it does not ask for the passphrase but the backup is created anyway.
    – Pabi
    Oct 11 '15 at 11:59










  • After doing that the output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
    – Pabi
    Oct 11 '15 at 12:09

















up vote
1
down vote













Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html



Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.






share|improve this answer























  • I am using gpg 2.1.8. If I run it without the passphrase env: duplicity --encrypt-key KeyID test scp://user@host/path it does not ask for the passphrase but the backup is created anyway.
    – Pabi
    Oct 11 '15 at 11:59










  • After doing that the output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
    – Pabi
    Oct 11 '15 at 12:09















up vote
1
down vote










up vote
1
down vote









Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html



Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.






share|improve this answer














Are you using gpg 2.1? if yes, duplicity and gpg need some extra parameters if you want to deliver the passphrase via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html



Alternatively simply do not set PASSPHRASE and gpg-agent will ask you and memorize the secret for you.







share|improve this answer














share|improve this answer



share|improve this answer








edited Oct 11 '15 at 16:40









Thomas Weinbrenner

715717




715717










answered Oct 11 '15 at 11:13









ede

25112




25112












  • I am using gpg 2.1.8. If I run it without the passphrase env: duplicity --encrypt-key KeyID test scp://user@host/path it does not ask for the passphrase but the backup is created anyway.
    – Pabi
    Oct 11 '15 at 11:59










  • After doing that the output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
    – Pabi
    Oct 11 '15 at 12:09




















  • I am using gpg 2.1.8. If I run it without the passphrase env: duplicity --encrypt-key KeyID test scp://user@host/path it does not ask for the passphrase but the backup is created anyway.
    – Pabi
    Oct 11 '15 at 11:59










  • After doing that the output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
    – Pabi
    Oct 11 '15 at 12:09


















I am using gpg 2.1.8. If I run it without the passphrase env: duplicity --encrypt-key KeyID test scp://user@host/path it does not ask for the passphrase but the backup is created anyway.
– Pabi
Oct 11 '15 at 11:59




I am using gpg 2.1.8. If I run it without the passphrase env: duplicity --encrypt-key KeyID test scp://user@host/path it does not ask for the passphrase but the backup is created anyway.
– Pabi
Oct 11 '15 at 11:59












After doing that the output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
– Pabi
Oct 11 '15 at 12:09






After doing that the output of file duplicity-full.20151011T115714Z.vol1.difftar.gpg lists a different KeyID then the one specified in --encrypt-key. I dont have the listed key in my keyring.
– Pabi
Oct 11 '15 at 12:09












up vote
1
down vote













I have had this issue when using sudo to execute duplicity, which makes it search for the private key into root's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.



The most simple solution to this problem was to avoid using sudo, in my case, by setting the correct permissions on the destination directory.



If sudo is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg" to the duplicity command, as stated on this answer



Maybe this helps someone else :-)






share|improve this answer























  • So how did you resolve exactly?
    – Pimp Juice IT
    Jul 18 '17 at 19:21






  • 1




    D'oh. Added to the answer. Thanks for pointing it out.
    – Pablo
    Jul 18 '17 at 20:19















up vote
1
down vote













I have had this issue when using sudo to execute duplicity, which makes it search for the private key into root's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.



The most simple solution to this problem was to avoid using sudo, in my case, by setting the correct permissions on the destination directory.



If sudo is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg" to the duplicity command, as stated on this answer



Maybe this helps someone else :-)






share|improve this answer























  • So how did you resolve exactly?
    – Pimp Juice IT
    Jul 18 '17 at 19:21






  • 1




    D'oh. Added to the answer. Thanks for pointing it out.
    – Pablo
    Jul 18 '17 at 20:19













up vote
1
down vote










up vote
1
down vote









I have had this issue when using sudo to execute duplicity, which makes it search for the private key into root's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.



The most simple solution to this problem was to avoid using sudo, in my case, by setting the correct permissions on the destination directory.



If sudo is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg" to the duplicity command, as stated on this answer



Maybe this helps someone else :-)






share|improve this answer














I have had this issue when using sudo to execute duplicity, which makes it search for the private key into root's home directory. Not finding the private key on it, the "No secret key" error appears and -at least for me- was not immediately clear why.



The most simple solution to this problem was to avoid using sudo, in my case, by setting the correct permissions on the destination directory.



If sudo is a must, then the appropriate GPG options need to set so it uses the user's GPG keychain: adding --gpg-options "~user/.gnupg" to the duplicity command, as stated on this answer



Maybe this helps someone else :-)







share|improve this answer














share|improve this answer



share|improve this answer








edited Jul 18 '17 at 20:18

























answered Jul 18 '17 at 18:52









Pablo

1115




1115












  • So how did you resolve exactly?
    – Pimp Juice IT
    Jul 18 '17 at 19:21






  • 1




    D'oh. Added to the answer. Thanks for pointing it out.
    – Pablo
    Jul 18 '17 at 20:19


















  • So how did you resolve exactly?
    – Pimp Juice IT
    Jul 18 '17 at 19:21






  • 1




    D'oh. Added to the answer. Thanks for pointing it out.
    – Pablo
    Jul 18 '17 at 20:19
















So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21




So how did you resolve exactly?
– Pimp Juice IT
Jul 18 '17 at 19:21




1




1




D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19




D'oh. Added to the answer. Thanks for pointing it out.
– Pablo
Jul 18 '17 at 20:19


















draft saved

draft discarded




















































Thanks for contributing an answer to Super User!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f984977%2fduplicity-restore-failing-no-secret-key%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Сан-Квентин

8-я гвардейская общевойсковая армия

Алькесар