nordvpn says cannot reach daemon: socket, group or unit?

Running nordvpn and getting a message about an unreachable daemon is a narrow complaint that usually arrives when you are already late. It says nothing about whether the tunnel works, because the CLI is only a front end: it talks to a background process over a Unix socket, and the message means that conversation did not happen. Walk outward from the command, stopping at the first thing that turns out to be false.

Start where the error appears

Two processes are involved, and confusing them is what makes this feel mysterious. The daemon owns the tunnel and listens on a socket under /run/nordvpn/. The command you typed connects to that socket instead of touching interfaces itself.

When the socket is missing or refuses the connection, the CLI has nobody to ask, so it reports the user-daemon or system-daemon variant of the same complaint. One of those variants names the path directly, which is the most useful sentence in the whole exchange.

Check the unit before anything else

Ask the service manager whether the daemon is running, then start and enable it in one step if it is not:

systemctl status nordvpnd
sudo systemctl enable --now nordvpnd
nordvpn version

If the unit exists but is inactive, enable --now both starts it and arranges the next boot. If the unit does not exist, the package is not the one you assume it is, and the installed name matters more than the name in your notes. That sounds like a pedantic distinction until you spend twenty minutes enabling a service that was never installed under that label. Read what is present, then act on it.

Listing the unit files settles that in one command, and it is worth doing before you conclude anything about the installation:

systemctl list-unit-files 'nordvpn*'
service --status-all

Releases have shipped the service under more than one unit name, so a build that uses nordvpn rather than nordvpnd will produce a perfect copy of this error while a healthy service runs right next to it.

The socket and its group decide access

Even with the daemon running, the connection can be refused on permissions. The installer creates a nordvpn group, and the socket is owned accordingly, so a user outside that group is denied while the service is perfectly healthy.

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

Group membership is read when a session starts, which is why the change appears not to work in the terminal where you made it. A fresh login shell or newgrp is required before the running session sees the new group. Test in a new shell, not in the one that just ran the command. Otherwise you will conclude the fix failed when it has simply not been applied yet.

Ownership of the socket itself is the second half of that check. Compare the group on the socket with the groups reported in the shell running the CLI, and the permission question is answered in one step rather than by reinstalling:

ls -l /run/nordvpn
id

A live process is not proof of the right socket. A daemon launched by another manager, or an old package that bound a differently named socket, reports identically. The directory listing tells those cases apart in one line, which is why it beats reinstalling.

The per-user process on older packaging

Some packaging runs a second process in the logged-in user context, which the desktop integration expects to find. If a system init script launches it without dropping to that account, the CLI goes looking for a daemon that no session owns.

On a non-systemd init the documented arrangement splits the roles: the system service runs under one name and the user-side process under the target account with chpst -u <user>. Check which arrangement your installation actually uses before adding a startup script that assumes the other one.

How to know you are finished

An upgrade is the usual trigger, because the new binary expects a service state the old one never left behind. Stopping, re-enabling and starting in that order clears it:

sudo systemctl stop nordvpnd
sudo systemctl enable --now nordvpnd
sudo systemctl start nordvpnd
nordvpn version

That last command is the acceptance test. A printed version means the socket answers, which moves every remaining fault into login, plan or connectivity territory and out of this article. If it answers, stop reading here and go and look at the account instead.

If the socket is still missing, read the unit journal to see why it exited, then check that /run/nordvpn exists and that the service account can write there. A process that comes up and dies at once records its reason in that journal, and one line is quicker to read than a reinstall is to perform.