NordVPN on Ubuntu: Daemon, Login and Clean Removal

Start with what the terminal reports, not with the installer. A vendor VPN client can fail because its background service is not running, because the package broke against a newer distribution, because the login flow changed, or because an old connection profile is still active. Each case leaves a different trace, and reinstalling fixes at most one of them. Move through the checks in order and stop when the evidence points at a layer.

Start With the Service, Not the Installer

Read the unit state first: systemctl status nordvpnd tells you whether the daemon runs and whether it restarted recently. A socket permission message such as Permission denied accessing /run/nordvpn/nordvpnd.sock is about group membership, not about the tunnel. Add the account to the vendor group, then sign out of the desktop session completely and back in. A fresh terminal keeps the old group list, so id is the only quick confirmation that the change applied.

When the daemon is healthy but the client ignores you, the package is the better suspect. A graphical entry that does nothing and a command that exits silently are package-level symptoms. After a distribution upgrade, a vendor manager written in Python can fail against a removed library API, so compare the installed build with what the vendor currently ships before purging anything.

Pick the Login Path the Build Offers

Login instructions from last year may describe a flag that no longer exists. On current builds, nordvpn login --legacy returns flag provided but not defined: -legacy, and the two supported paths are a portal token and a browser callback. For the token path, generate it in the account page and pass it once: nordvpn login --token <token>. For the callback path, copy the success address, swap https:// for nordvpn://, and quote the result when you hand it to nordvpn login --callback.

Both values are credentials. A token without an expiry is handy on a headless box and expensive in shell history, so clear it after use and keep it out of support bundles.

Uninstall Completely, Repository Included

Removal has three parts: the package, the apt source and the group membership. Purging the package alone leaves a repository that keeps answering apt update, and a stale group that keeps granting access to a socket nobody should own. If the client came from a downloaded .deb, resolve the exact package name with dpkg -l | grep -i nordvpn first, because guessing produces a purge that removes nothing.

Keep the vendor's own uninstall instructions if they exist, and record what you removed so a later reinstall does not silently inherit half a configuration.

sudo apt purge nordvpn
sudo rm /etc/apt/sources.list.d/nordvpn.list
sudo gpasswd -d "$USER" nordvpn

Remove Profiles the Uninstall Forgot

NetworkManager keeps connections in its own store, and a client that wrote one during setup can leave it active long after removal. The known culprit is pvpn-ipv6leak-protection. Enumerate with nmcli connection show and nmcli connection show --active, note the UUID, and delete by that identifier so you do not remove a live profile. If the entry reappears after a reboot, delete its keyfile under /etc/NetworkManager/system-connections/ and restart NetworkManager.

Do not empty that directory. Other VPNs and ordinary wired profiles live there too, and a cleanup that removes them creates a second outage. Entries saved by other vendors deserve the same caution: a saved server profile is not a running daemon, and deleting one is a configuration decision rather than a bug fix.

Login Is Not the Same as a Working Tunnel

A successful login only proves the account authenticated. If the tunnel starts but names stop resolving, inspect the technology the client selected and the resolver state before changing the account. Some builds expose a second data path, and moving to it is the documented workaround when the newer one fails to start.

Traffic that breaks only while connected points at a kill switch or a leftover leak-protection profile, not at another login. Local devices need a separate look: a printer or file server that disappears during the session is usually blocked by the vendor's LAN exception list rather than by the router.