I have just restored my data from a borg backup repository after a computer failure.

My ~/.gnupg folder seems fine, private keys are there, and permissions look correct. Usually borg does a good job at this. When I cat the private keys files, there is no sign of data corruption.

However I cannot list or use the private keys. I can only interact with a public key that was imported by pacman during the installation process.

I came across a few posts with similar issues of private keys not recognised after being copied from one machine to another, and usually the problem gets solved following recommendations of repeating the transfer using gpg —export-key and then importing them with the opposite command.

Unfortunately I do not have that luxury since my old machine has crashed and is not recoverable. I was aware of importing and exporting keys, but I always assumed it was just a safe procedure to move keys around.

So I have two questions:

Do I have to review my backup scripts and use the export command for my gpg secret keys?

Can I recover my secret keys nonetheless?

======= Edit ======

I found a post on arch forum with a user having exactly the same problem I have, so I got more leads to follow.

What I tried so far:

gpg --version
> gpg (GnuPG) 2.4.5

ps aux | grep gpg-a
>  /usr/bin/gpg-agent --supervised

#About ownership: 
chown -R $USER:$USER .gnupg

# Checking UID/GID with show a result of `1000` both on filesystem # # and backup archive.
ls -vn .gnupg/private-keys-v1.d 

gpg --export-secret-keys
> gpg: WARNING: nothing exported

gpg -v --list-secret-keys
> gpg: enabled compatibility flags:
> gpg: using pgp trust model

# Most relevant results of:
strace -f -o /tmp/gpg.strace gpg --list-secret-keys
cat /tmp/gpg.strace
> 76220 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> 76220 access("/home/$USER/.gnupg/secring.gpg", F_OK) = -1 ENOENT (No such file or directory)

# Listing public keys
gpg --list-keys
> Returns one public key imported by pacman during install

gpg -K
> Returns nothing

ls -ln .gnupg/
.rw-r-----   12 1000 13 Mar 10:45 common.conf
drwx------    - 1000  6 Sep  2023 crls.d
.rw------- 2.0k 1000 13 Sep  2023 gpg-agent.conf
.rw-------  703 1000  5 Mar 18:48 gpg.conf
drwx------    - 1000 30 Aug  2023 private-keys-v1.d
drwxr-x---    - 1000 14 Mar 19:27 public-keys.d
.rw-r--r--    0 1000 24 Aug  2023 pubring.gpg
.rw-r--r-- 7.7k 1000  5 Mar 12:13 pubring.kbx
.rw-r--r-- 7.0k 1000  7 Sep  2023 pubring.kbx~
.rw-------  600 1000  8 Mar 07:20 random_seed
.rw-r-----  676 1000 30 Aug  2023 sshcontrol
.rw------- 1.6k 1000  2 Sep  2023 trustdb.gpg
  • Please update your question with the output of ls -l ~/.gnupg; that will help us understand the current state of things. Also, does gpg -K produce no output, or are you getting an error?
    – larsks
    Commented Mar 13 at 20:47
  • (Assuming 2.1 up) do you have valid pubring.kbx and is gpg -k (or gpgsm -k if you use smime) correct? gpg (and gpgsm) uses the publickey ring to identify the keys and won't list or use a secret=privatekey that doesn't have a matching publickey. Commented Mar 14 at 1:58
  • Thanks for the interest.gpg -K returns nothing, the pubring.kbx is present, I have no idea if it is valid though. I added all the new info I could gather in the EDIT section at the end of my original post.
    – lyndhurst
    Commented Mar 14 at 18:13
  • I forgot; gpg 2.4.5
    – lyndhurst
    Commented Mar 14 at 19:28

1 Answer 1


I am trying a garuda kde install at the moment, and it turns out it comes with some default gpg settings I have not yet completely figured out.

Anyway, it turns out some process is constantly recreating a basic .gnupg folder. It does not look like it is to blame on gpg agent since I was able to disable all gpg related systemd services (mainly gpg-agent.service and gpg-agent.socket) as both user and root and then killall gpg-agent.

What was happening is that I would never actually restore my own gpg folder from backups, but merging it with an automatically created and for some reasons it would not work.

Finally just to make sure I found the culprit, I could rm -rf the folder and restore it from backup using a script so that whatever process xas recreating it would not have the time to do so.

It has been working fine since.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .