This fixes the " gpg: WARNING: unsafe permissions on homedir '/home/path/to/user/.gnupg' " error while using Gnupg .

Correct_GnuPG_Permission.sh

#!/usr/bin/env bash

# To fix the " gpg: WARNING: unsafe permissions on homedir '/home/path/to/user/.gnupg' " error
# Make sure that the .gnupg directory and its contents is accessibile by your user.
chown -R $(whoami) ~/.gnupg/

# Also correct the permissions and access rights on the directory
chmod 600 ~/.gnupg/*
chmod 700 ~/.gnupg

The problem with blindly setting the root directory to 700 and the nested file descriptors to 600 is that nested file descriptors that represent directories won't have the proper permissions.

The resulting consequence is that anything requiring execute permission within a nested directory will fail (i.e. gpg --send-keys):

user@host:~$ gpg --send-keys 1b842cb5
gpg: connecting dirmngr at '/run/user/1000/gnupg/S.dirmngr' failed: IPC connect call failed
gpg: no keyserver known
gpg: keyserver send failed: No keyserver available

To ensure proper permissions definitely either use the find method specified above - or leverage an additional step:

1. chown -R $(whoami) ~/.gnupg
2. chmod 700 ~/.gnupg
3. chmod 600 ~/.gnupg/*
4. chmod 700 ~/.gnupg/*.d

The error demonstrated is the result of the crls.d directory not having the exec permission when trying to send keys without a keyserver specified:

user@host:~$ ls -la ~/.gnupg
total 136
drwx------  5 rik rik  4096 Jun 12 13:09 .
drwxr-xr-x 63 rik rik  4096 Jun 11 00:15 ..
drw-------  2 rik rik  4096 Jun  9 03:28 crls.d    <---- Notice this here
-rw-------  1 rik rik    79 Jun  9 03:28 gpg.conf
drw-------  2 rik rik  4096 Jun  9 03:28 openpgp-revocs.d
drwx------  2 rik rik  4096 Jun  9 16:41 private-keys-v1.d
-rw-r--r--  1 rik rik 17389 Jun  9 15:34 pubring.kbx
-rw-------  1 rik rik 17386 Jun  9 03:28 pubring.kbx~
-rw-------  1 rik rik   600 Jun 10 07:19 random_seed
-rw-------  1 rik rik     7 Jun 11 23:36 reader_0.status
-rw-r-----  1 rik rik   676 Jun  9 16:30 sshcontrol
-rw-------  1 rik rik 49152 Jun  9 15:34 tofu.db
-rw-------  1 rik rik  1560 Jun  9 03:28 trustdb.gpg

I've added this reply simply because this discussion has been my goto for fixing permissions issues with the .gnupg directory and so it's easiest to just see this addition here.

Thank you all for your advice and methods.

One command. chmod -R u=rw,u+X,go= ~/.gnupg/

Or, even easier, with assumption that we DO have correct access to the directory already, and merely want to fix permissions:

chmod -R go= ~/.gnupg/

Also note that this only works on POSIX systems.

thanks alot for this

Thank you for documenting this and for the updated answer @kirvedx worked perfectly 👍

@kirvedx Thanks for documenting this :)

@kirvedx Thanks for sharing. Your approach is what worked for me. Thanks!

One command. chmod -R u=rw,u+X,go= ~/.gnupg/

@AnrDaemon , why u=rw,u+X, shouldn't just u=rwX do the same thing?

I'm using this, and it seems to work correctly, and has proper quoting to make shellcheck happy. It even creates the directory if it doesn't exist, because in my case this is part of an automated script that I use to set up new computers (so it's possible this is the first time running GnuPG):

mkdir -p "$HOME/.gnupg/"
chown -R "$(whoami)" "$HOME/.gnupg/"
chmod -R u=rwX,go= "$HOME/.gnupg/"

X sets executable bit if a file is a directory or already executable. When you want to RESET executable bit but keep directories accessible, you first clear everything unwanted (u=rw,…), then set correct bits for directories (…,u+X).

I'm using this, and it seems to work correctly

Only as long as it has no wrongly +x'd files.

Ah, right, that makes sense. In this case using u+X is probably better, but in a general case it's probably better not to wipe the executable bits for files that already have them.

:) In a general case, there's no general case, you do what needs to be done.
In my case, I often need to clear unnecessary +x set by Windows systems accessing directory over Samba share.

Line 8 changes the permissions on the files in the ~/.gnupg/* directory to 700. 700 means that only the owner/creator can Read, Write and Execute on the files in the directory. Also group and others cannot perform any operation on the files in the directory.

Permissions on a directory are a bit different than for a file. Read on a directory allows you to list the directory contents. Write allows you to create or delete files in the directory. Execute allows you to access files or directories in the directory (i.e., open them). Execute without read is allowed, so you can open files if you know their pathnames even though you cannot list the contents of the directory.

Yes, what @Eric-Catalyst says is correct.

Thanks guys. Thanks @AnrDaemon. I incorporated those changes, in my case looks like I just mkdir first so ownership is fine, I just need to change file/folder permissions.

Then I just add:

chmod -R u=rw,u+X,go= ~/.gnupg

I hope that's compatible on various OS, like Mac/Linux etc. Should be, right? Anyway, here's the repo I added that changes to. It has a script to simplify set up of SSH and GPG stuff on a new mac. Hope it helps someone else out, let me know if so.

I seem to be the odd one out for this, I just installed ezarcher and I've tried everyone's suggestions. Not one of them worked for me. When I run ls - la or -ld it says that I'm the owner of /.gnupg. but when I try to run anything with sudo like pacman-key --init I get "gpg: WARNING: unsafe permissions on homedir '/root/.gnupg' ". I even did the gpgconf --kill all and gpgconf --kill dirmngr. I'm hope that someone e has come up with another option by now

Thank
Aunt13

sudo without an explicit user specification defaults to user #0 (usually named root).

Please show an actual output of sudo getfacl /root/.gnupg for further diagnostics.