Why a VPN Service Started at Boot Cannot Read Your Keyring

A connection that works after login and fails before it usually means the boot-time attempt could not obtain a secret, not that the server rejected one. The credential exists; the context asking for it does not. That single distinction saves an unnecessary password reset.

Follow the request: something starts the connection before a desktop session exists, and the secret store that normally answers has not been unlocked. The two contexts disagree about who owns the secret, and the profile records which of them is expected to supply it.

What the boot path actually asks for

At boot, NetworkManager starts as a system service with no user session, no session D-Bus and no unlocked keyring. A connection profile can still be brought up, but only with secrets the service can reach on its own. Anything owned by a secret agent stalls until a human logs in and the agent appears. The service is doing exactly what its configuration says; the profile is the thing that has to change.

The failure is written into the connection rather than hidden in a keyring.

Reading the secret flags on a connection

Ask the connection what it expects, not what the desktop remembers. The flags column answers the question directly, and it survives reboots in the profile file on disk.

Start with the profile list, then confirm which connection is set to come up on its own. Then dump one connection and read the password flags:

nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
nmcli connection show "Work VPN" | grep -i -E "password|secret|key"
journalctl -b -u NetworkManager --grep "secret"

The first command confirms which profiles exist and whether one is set to autoconnect, which is how an unattended attempt gets started in the first place. The second exposes the flag values, and the third shows the service complaining that no agent answered for a given secret. A log line naming a secret as agent-owned is the whole diagnosis in one sentence.

Why moving the connection to system scope changes the answer

A connection owned by a user is activated under that user's agent, which is why it works perfectly once the desktop is up. Moving it to system scope removes the agent from the path, so the same profile behaves differently without a single line of VPN configuration changing.

That move is a legitimate design, and it carries a requirement: the secret has to be reachable by the system service. Storing it in the profile, providing it through a system-scoped credential, or accepting an interactive prompt at the right moment are all valid answers. Leaving flag 1 and hoping is not.

A private key with its own passphrase adds a second layer. Even a stored account password will not unlock a key that wants a passphrase, so verify which secret the failing stage is actually asking for before changing anything.

What not to do, and what to do instead

Making every credential file world-readable, or disabling authentication so no prompt is needed, trades a startup inconvenience for a permanent exposure. Both also hide the dependency rather than resolving it, and the next image update reintroduces the same failure.

Use the mechanism your distribution documents for unattended activation at that stage, then confirm the profile's flags match it. Check the result from a clean boot rather than from a shell that already has an agent. Write down the connection owner, the secret source and the stage that must work, so a later autostart change cannot quietly reintroduce a dependency on somebody unlocking a desktop first. Documentation is the difference between a fixed service and one that breaks again next quarter.

Test from a controlled clean boot rather than a manual retry after login. The retry succeeds for the reason the boot attempt failed, which is exactly the evidence a quick test destroys.