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

Thanks a lot, this fixed the gpg warning!

I'm curious about how it fixed the warning, can you please explain a bit, specifically line 8 and 9?

Thanks in advance!

@sf9v,

Glad that this helped to fix the warning.

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.

Line 9 changes the permissions on the ~/.gnupg directory to 600. The 600 directory permission means that only the owner/creator of the directory can Read and Write but can't Execute on the directory. The group and others cannot perform any operation on the directory.

Awesome, will keep this for future reference. Thanks a lot @oseme-techguy!

How about using find?

find ~/.gnupg -type f -exec chmod 600 {} \; # Set 600 for files
find ~/.gnupg -type d -exec chmod 700 {} \; # Set 700 for directories

The internal directory .gnupg usually contains other directories, so it seems to me that setting permissions through find would be a better solution.

The commands given by @ElXreno are correct: The directory containing the private keys should be traversable by the user who own it, or GPG won't be able to read the private keys.

I am having trouble with this "gpg: WARNING: unsafe permissions on homedir" on my Windows computer. I have been using gpg4win 3.1.11 (a Windows version of gpg) for over 3 years but I suddenly started to get this warning about a week ago and have been unable to use gpg since then.

Does anybody know what Windows permissions are needed to make gpg4win work again?

Issue: gpg failed to sign the data after git commit -m 'sample text'

I want to push my changes to GitHub in Git command, integrated terminal in VSC, and my profile is Bash, customized in ZSH. I'm deploying to Netlify through continuous deployment from Github.
Every time I do "git commit -m "xyz', I get error:

husky > pre-commit (node v14.17.5)
⚠ Some of your tasks use `git add` command. Please remove it from the config since all modifications made by tasks will be automatically added to the git commit index.

ℹ No staged files match any configured task.
error: gpg failed to sign the data
fatal: failed to write commit object

We think it is an authentication issue, related to gpg key. We're able to run gpg2, but not able to sign in with key. We're trying to set the program to gpg2, and we have upgraded to gpg2, but it says it is already installed gpg. How to check what is gpg key?
We are not sure where to look/what to do now.
Previously I had problems with visibility of my contributions to Gihub, so I have gained Netlify permission to access my repository code. Netlify does this by installing the Netlify GitHub App on my Github account. Everything worked perfect, until I have updated my Macbook Air from Mojave to Big Sur v11. In the same time I had to update my terminal, so I screwed Homebrew upgrade. Yet, my profile is just Bash. Not sure about the last one, sorry! Not least, but last, Netlify just announced Netlify API Authentication beta version to enable in my settings. I haven't enabled it yet, but I'm not sure if these are the source of my issue.

thanks a lot

How about using find?

find ~/.gnupg -type f -exec chmod 600 {} \; # Set 600 for files
find ~/.gnupg -type d -exec chmod 700 {} \; # Set 700 for directories

The internal directory .gnupg usually contains other directories, so it seems to me that setting permissions through find would be a better solution.

Thank you! This worker perfectly.

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.

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.

I'm still learning Linux; what is it "go=" in

chmod -R go= ~/.gnupg/

mean?

~ thank for this btw

I'm still learning Linux; what is it "go=" in

chmod -R go= ~/.gnupg/

mean?

Unix/Linux file permissions have rights for the user, group, and other. A file is owned by a user and a group, and you can set read, write and execute permissions for the owning user, group, and all other users.

chmod uses u, g, and o as shorthand for "user", "group" and "other" respectively. You can also use a for all users.

Some examples:

• u=rw sets the permissions to read and write (and removes the execute permission) for the user
• g+x adds the execute permission for the group, bur doesn't change the other permissions (resd and write stay unchanged)
• o-w removes the write permission for other users, but doesn't change read and execute permissions
• a+X adds the execute permission for all users, but only for directories (nor for files); very useful when recursively setting permissions with -R (the execute permission for a directory is needed to be able to list files)

So, go= sets the group and other permissions to an empty list for the group and other users. In other words, it removes all permissions for the group and other users. You could also use go-rwx (a bit more descriptive, but longer).