One Profile, Two Owners: NetworkManager or systemd

Nothing happens with a .ovpn file until something owns it. On a Pi desktop the plausible owners are NetworkManager, which stores an imported connection in its own keyfile, and a standalone service unit that reads a configuration from a directory. Those are two operating models with different storage, different credential handling and different activation rules. Choosing one deliberately is the whole task; copying the file into both places just makes the choice accidental.

Both can work on one machine, but not on the same tunnel at the same moment, and the conflict looks like a network fault rather than a configuration one.

Two Ways to Own the Same Tunnel

NetworkManager's OpenVPN plugin adds an editor and a service that manage the connection for you, and installing the OpenVPN binary does not install that integration. A standalone unit is the opposite arrangement: no editor, no desktop integration, one configuration file and whatever privileges the unit grants. The first keeps connection state in its own database, the second keeps it wherever the profile and the unit say. Most confusion comes from assuming an imported profile and a copied file are the same object.

They are not two views of one thing. Editing the downloaded file changes neither what NetworkManager saved nor what the unit reads, and either may be the one that built the tunnel you just tested.

Follow the Connection the Desktop Actually Uses

The documented import operation, nmcli connection import type openvpn file office.ovpn, creates a connection through the plugin. Record its UUID and use that identifier afterwards, because names get edited and two connections can share a label. nmcli connection show lists what exists, and reading a connection's own properties tells you which file it came from and what it stores. If the UUID you are editing is not the one the desktop activates, your edits are decoration.

Secrets live in the owner's storage. Dumping every saved secret to work out which profile is active is slow and risky; ask the connection object instead, and keep private material where the owner expects it.

An imported connection does not need a graphical session to run, but it may still need a credential source. Whether it starts unattended depends on its permissions and secrets, not on the desktop being present.

Read the Unit Template Before Relying On It

Where the package ships the upstream-style client unit, an instance named office maps to %i.conf inside the unit's configured directory, which for the 2.6 template is /etc/openvpn/client. Read the installed unit and any drop-ins before trusting an example from a guide, because distributions relocate paths. A manual launch from a terminal proves nothing about the service's view of files, secrets or permissions. The desktop password dialog is also not evidence that a noninteractive unit has an approved way to obtain the same password.

Grant the unit only what it needs. Relaxing the whole service sandbox because one referenced file is unreadable trades a small permission fix for a large exposure, and the error usually names the file that needs attention.

Retire the Duplicate Without Losing Access

If both owners can start the tunnel, one eventually wins at the wrong moment and the loser's routes and device are left behind. Remove the accidental duplicate through its own owner, keep a recovery path open, and confirm the remaining owner still connects after a reboot. Two deliberately separate VPNs with different routing policies are a different design question, not permission for two launch paths to compete over one connection.

Then write down the lifecycle you accepted: manual activation, login, or boot and reconnect. Check the saved endpoint, the peer authentication and the resource the tunnel is meant to reach, since reinstalling the desktop cannot substitute for knowing which configuration ran.