Hello!
When I want to encrypt and sign a message on the command line, I get an error message:
“can’t connect to ‘socket:///home/user/.gnupg/log-socket’: Connection refused” - How can I solve the problem without lowering security?
I’ve done a lot of research but there are no solutions, apart from old versions of Gnupg.
This is a real problem and I’ll give it to you straight.
I have the impression that nobody has a solution.
For information, I use ArchLinux.
Thanks!
Hi @alexandre0123
this problem seems to be ArchLinux specific.
Here is the page GnuPG - ArchWiki that has a number of hints how ArchLinux’s default configuration looks like.
That message
“can’t connect to ‘socket:///home/user/.gnupg/log-socket’: Connection refused”
relates to logging actions which is optional, so you can turn it off.
Set --log-file to a real file that gpg can write and only you can read in your call on the command line. And add an -v to see a little more details.
You may need to check if other components have this option in their configuration file, if changing the call to gpg is not enough. See the different log-file options in Option Index (Using the GNU Privacy Guard)
Best,
Bernhard
I had the same problem, found a solution here:
https://bbs.archlinux.org/viewtopic.php?id=296399
So I edited gpg.conf and gpg-agent.conf and changed the logfile from a socket to a local file:
log-file /home/lpc123/.gnupg/gpg.log
Hello, thanks you for answers @bernhard and @stokito
When I change the location of the socket to a folder that has read and write permission, I still get the same error message, except that the error message with the new socket path.
I tried to do what you told me but I still have the same problem, socket file is a hell for gnupg.
Finally, I deleted the .gnupg folders in /root and in the home file.
Then I run the following commands:
I added lines concerning the servers to receive the public keys in dirmngr.conf and I deactivated the line concerning the file linked to the socket.
There is no problem, but until when ?
To avoid losing public and private keys, I use kleopatra.
So I used kleopatra via AppImage, because kleopatra does not launch on ArchLinux and I want to avoid using Xorg at all costs, only Wayland.
I can save the public keys in a single block but also to save the private keys which are saved in an encrypted container via cryptsetup.
Indeed, I am sure that the socket problem will reappear and I do not understand the problem with the socket.
so if the problem reoccurs, I will use this method.
Thanks you !
No, I see the same problem on openSUSE Tumbleweed. Both are rolling releases - may that be the issue?
There is no problem, but until when ?
Until you again do not have a server running which is listening at that socket…
Your error message “can’t connect to ‘socket:///home/user/.gnupg/log-socket’: Connection refused” is typical for this. Gpg can not connect to a socket where no one is listening.
And when you define a socket for logging in one of your .conf files, this will happen sooner or later.
So my advice is to use a log file as @stokito suggested, which will always work as long as the file is writeable. Alternatively only enable a log socket for a debug session where you are more likely to remember to start your log server (e.g. watchgnupg), too.
By the way: if you use Kleopatra instead of the command line to encrypt something, you won’t see any error message at all in the case your log server is not running. You will sit there wondering why Kleopatra doesn’t start as expected until you remember that you had enabled logging via socket the day before but didn’t start watchgnupg yet… As happens to me once in a while 
Hi @docB!
It’s not an issue of rolling releases. I assume you configured the log socket yourselves, in that case its a misconfiguration by the user. It could theoretically be a misconfiguration in the global config files by the maintainers of these distributions, too, but I guess then we would get more questions regarding this.
Hello Bernhard,
It’s not an issue of rolling releases.
Sure - rolling releases usually have the latest version of gnuPG available, so if it is a regression we will see it first.
I assume you configured the log socket yourselves, in that case its a misconfiguration by the user. It could theoretically be a misconfiguration in the global config files by the maintainers of these distributions, too, but I guess then we would get more questions regarding this.
I have not touched this at all, but opened a bug: 1226912 – gnupg problem with socket connection
Ok, after consulting with a colleague this might be an issue with kwatchgnupg. Which is the tool started when you click on Tools → “GnuPG Log Viewer” in Kleopatra. (But it can be started on the command line, too.)
This then writes the line log-file socket:///home/user/.gnupg/log-socket in all existing .conf files in you GNUPGHOME apparently and does not delete them again when logging is stopped.
Did you start kwatchgnupg in the past? Maybe unintentionally
This is usually only annoying, as the message is only a message warning you that no log can be written to the socket and logging will then fall back to STDOUT.
But if you have kwatchgnupg or watchgnupg running, you will get all dignostic output there and not in your terminal. Which is very confusing. But gpg should do the operation anyway, e.g. encryption. But in your case is was a verification and that result will only appear in the log viewer. Do you have one running? Can you confirm you see the output there?
In any case when you delete all the log-file lines in your configuration files in GNUPGHOME which point to a socket you will see the output again on the command line.
Kwatchgnupg has not changed in some years AFAIK, so I’m not sure if something else has triggered some change in the behavior. Can you point to a specific update after which this started to happen?
Anyway, we will think about how to improve that irritating behavior of Kwatchgnupg in the future.
I just checked with ps, I have no such process running
As witten, no such log viewer. I would not mind about the missing log, but gnupg does not perform the verification, and stops with this error.
Not really, as I dont use gnupg on the command line that often, but had to deal with a failing tarball signature, when I detected the issue.
Deleting the lines from the config files helped, thank you!
In all likelihood it does, but the verification result is send to the log file / socket.
Seems the fallback to stdout does not work for you then, strange.
Your welcome!
Hi,
somehow I was of the understanding after looking at the ArchLinux Wiki files that they may do something special with sockets. Good that you did more analysis that a kwatchgnupg run may have added that configuration. Haven’t seen this before either.
Hello,
The problem seems to have been solved in my case.
The problem has been solved by updating GnuPG and libgcrypt ( Archlinux gnome)
So I can check file signatures without error messages.
logs:
[2024-06-28T22:02:20+0000] [ALPM] upgraded gnupg (2.4.4-1 → 2.4.5-1)
[2024-06-28T19:59:18+0000] [ALPM] upgraded libgcrypt (1.11.0-1 → 1.11.0-2)
@DocB:
I did a test under Opensuse Tumbleweed with virt-manager and I did not see any problems with gnupg.
It seems that rolling release distributions also have problems, which is normal.
There is also a problem with kleopatra, but there is an Appimage that you can download from the following link:
This sounds amazing as I found it very much useful and informative to be honest. Also, I have gone through this post which definitely helped me out a lot as a new member I am looking forward for more such discussions.
@bernhard, although I’ve observed corroborations for Arch, at:
bbs.archlinux.org/viewtopic.php?pid=2175265#p2175265
reddit.com/r/archlinux/comments/1caz3sn
…I’ve recently experienced this:
RokeJulianLockhart@Beedell:~/Downloads$ gpg --decrypt launchpad.pgp can't connect to 'socket:///home/RokeJulianLockhart/.gnupg/log-socket': Connection refused
…when attempting to decrypt reddit.com/r/ProtonMail/comments/ii23f8/comment/o115pro on another OS, with gpg --decrypt $filename, from:
#!/usr/bin/env sh
rpm -qi $(rpm -qf $(command -v gpg))
Name : gnupg2 Version : 2.4.9 Release : 1.fc43 Architecture: x86_64 Install Date: Mon 05 Jan 2026 16:37:41 GMT Size : 6869331 Signature : RSA/SHA256, Fri 02 Jan 2026 09:36:24 GMT, Key ID 829b606631645531 Source RPM : gnupg2-2.4.9-1.fc43.src.rpm Build Date : Fri 02 Jan 2026 09:26:07 GMT Build Host : buildhw-x86-08.rdu3.fedoraproject.org Packager : Fedora Project Vendor : Fedora Project Bug URL : https://bugz.fedoraproject.org/gnupg2
…and lists.gnupg.org/pipermail/gnupg-users/2025-April/067584.html corroborates that this affects Ubuntu, whereas lists.gnupg.org/pipermail/gnupg-users/2025-June/067690.html cites openSUSE.
Strangely, I also note that it cites t/4669/8, which is 404, now.
I’m a new user, so I intended to post:
[quote="bernhard, post:2, topic:4669"]
This problem seems to be ArchLinux-specific.
[/quote]
@bernhard, although I've observed corroborations for Arch, at:
- [`bbs.archlinux.org/viewtopic.php?pid=2175265#p2175265`][1]
- [`reddit.com/r/archlinux/comments/1caz3sn`][2]
…I've recently experienced this:
> ~~~YAML
> RokeJulianLockhart@Beedell:~/Downloads$ gpg --decrypt launchpad.pgp
> can't connect to 'socket:///home/RokeJulianLockhart/.gnupg/log-socket': Connection refused
> ~~~
…when attempting to decrypt [`reddit.com/r/ProtonMail/comments/ii23f8/comment/o115pro`][6] on another OS, with `gpg --decrypt $filename`, from:
1. ~~~sh
#!/usr/bin/env sh
rpm -qi $(rpm -qf $(command -v gpg))
~~~
1. <blockquote>
~~~YAML
Name : gnupg2
Version : 2.4.9
Release : 1.fc43
Architecture: x86_64
Install Date: Mon 05 Jan 2026 16:37:41 GMT
Size : 6869331
Signature :
RSA/SHA256, Fri 02 Jan 2026 09:36:24 GMT, Key ID 829b606631645531
Source RPM : gnupg2-2.4.9-1.fc43.src.rpm
Build Date : Fri 02 Jan 2026 09:26:07 GMT
Build Host : buildhw-x86-08.rdu3.fedoraproject.org
Packager : Fedora Project
Vendor : Fedora Project
Bug URL : https://bugz.fedoraproject.org/gnupg2
~~~
</blockquote>
…and [`lists.gnupg.org/pipermail/gnupg-users/2025-April/067584.html`][3] corroborates that this affects Ubuntu, whereas [`lists.gnupg.org/pipermail/gnupg-users/2025-June/067690.html`][4] cites openSUSE.
Strangely, I also note that it cites [`t/4669/8`][5], which is 404, now.
[1]: https://bbs.archlinux.org/viewtopic.php?pid=2175265#p2175265:~:text=can%27t%20connect%20to%20%27socket:///home/lpc123/%2Egnupg/log%2Dsocket%27:%20Connection%20refused
[2]: https://www.reddit.com/r/archlinux/comments/1caz3sn/gnupglogsocket_refuses_connection/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
[3]: https://lists.gnupg.org/pipermail/gnupg-users/2025-April/067584.html#:~:text====-,The%20issue%20is%20therefore%20not,===,-My%20config%20hasn%27t
[4]: https://lists.gnupg.org/pipermail/gnupg-users/2025-June/067690.html#:~:text=It%20is%20fixed%20in%20libcrypt,https://bugzilla%2Eopensuse%2Eorg/show_bug%2Ecgi%3Fid=1226912%23c3
[5]: https://forum.gnupg.org/t/problem-with-socket-connection-refused/4669/8
[6]: https://www.reddit.com/r/ProtonMail/comments/ii23f8/comment/o115pro/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
I’m confused, this ticket was about an issue witch was caused by the lines
log-file socket:///home/user/.gnupg/log-socket
In various .conf files in the gnupg folder.
This is not Arch specific, its a kwatchgnupg thing. Bernhard was mistaken in this case.
Either you have the same issue, then see above for the fix our you have an other issue then please open a new thread. It is bad form to post into old tickets. Instead refer to them via link in your new post.
@eebb, all that I have seen is one person stating that updating some packages remediated this for them. Considering that that didn’t remediate this for me (I’m using libgcrypt-1.11.1-3.fc43), I believe that demonstrating, to anyone who might come across this thread, that it isn’t a solution, is helpful.
I’ve the same problem, and surely two threads for the same problem would be nonsensical?
It’s from 2024. That’s barely a year ago…
Does any ticket track this? I ask because a user shouldn’t need to modify broken-by-default configuration files upon installation, I presume.
[Kwatchgnupg writing configuration files, that later trigger problems]
Does any ticket track this?
Seems to be ⚓ T7259 Kleopatra: Kwatchgnupg must not modify conf files
The challenge in this issue is that it feels like some things have been mixed up. So I’d also would have preferred a new issue which potentially could have a new cause, but I can understand and it is fine that you have posted here.
To summarize my understanding:
If an error like the following is shown:
can't connect to 'socket:///home/RokeJulianLockhart/.gnupg/log-socket': Connection refused
Check your configuration files if such a log-socket is configured in there. Remove it, if you do not know why it is there and what it is for.
As general recommendation: Do not use kwatchgnupg until you get a version that has been cleared towards changing the configuration. Use watchgnupg in a terminal instead.
There maybe other causes or helping scripts done by GNU/Linux distributions and their packagers for the error message, but the root case will be that the crypto engine (and its components) tries to write to that socket and can only do so if there is someone reading the socket at the same time.
@RokeJulianLockhart does removing the log-socket configuration resolve your problems?
(Just to be sure: You can use Kleopatra to decrypt a GnuPG or OpenPGPv4 message, that is unrelated.)
@bernhard, thank you!
My apologies, in that case. I didn’t imagine that multiple causes might be probable. If it shall be helpful, I don’t mind if my responses (and all others’ responses to mine, thereafter) are split into a new thread.
Although I presume that some easily-accessible documentation provides the location of the relevant files, I’ve yet to locate which:
Are you able to point me in the correct direction? Apologies if this should be obvious.
I don’t believe that I’ve ever deliberately enabled it, and rpm -qa | grep -E 'kwatch|watchgnu' returns $Null. Consequently, if it’s enabled, by default, by Kleopatra, I’m uncertain how one might disable it.
Hi @RokeJulianLockhart,
to find the configuration files, see GPG Configuration (Using the GNU Privacy Guard) and Dirmngr Configuration (Using the GNU Privacy Guard)
to cite the situation for a “normal” GNU/Linux installation from Agent Options (Using the GNU Privacy Guard)
–homedir dir
Set the name of the home directory to dir.If this option is not used, the home directory defaults to ~/.gnupg.
It is only recognized when given on the command line.
It also overrides any home directory stated through the environment variable GNUPGHOME