Grey NetworkManager Control? Check Ownership Before Permissions

Greyed-out VPN switches in the desktop menu report that something is wrong and nothing about what. That is an observation, not a diagnosis. Three different boundaries can produce the same dead control: NetworkManager may not own the device, the session may lack the permission to change it, or the VPN editor plugin may not be installed at all. Changing the wrong one is how a five-minute fix becomes an afternoon of reinstalling packages.

Three read-only commands separate the cases before anything is modified.

Ask the three questions in order

nmcli device status
nmcli general permissions
nmcli connection show

These are inspection commands for a system that actually uses NetworkManager, and they are safe to run as an ordinary user. Keep private connection details out of public logs if you paste the output anywhere.

Device status answers whether the interface is managed and usable. The permission view answers what the calling session is allowed to do. The connection list shows which profiles exist; it does not prove that a matching VPN editor or import plugin is installed.

Ownership and permission are different faults

A device marked unmanaged is outside NetworkManager's control, and no amount of permission will produce a working toggle. The ifupdown plugin is one common cause: its managed setting decides how entries in the interfaces file are treated, and a leftover stanza can keep an interface under the old tooling. The file's existence is not an instruction to delete its contents, and removing entries you did not write is a good way to lose connectivity.

Permission is a separate axis. NetworkManager authorizes non-root callers through PolicyKit, and the reported answer can be yes, auth, or no. A session without an authentication agent reports auth and then fails silently in the desktop, which looks like a broken control rather than a missing agent.

Do not fix either by running the desktop as root

Running the whole session as root to make one toggle work changes the security model of every application on the machine. It also hides the underlying misconfiguration instead of documenting it. If an action needs administrative authorization, that is the intended design, and the fix belongs in policy or in how the agent is started.

Likewise, do not launch a second copy of NetworkManager or a competing daemon. Two managers arguing over the same device produce state that is hard to reason about and harder to support. If a second daemon looks like the only way to get a control back, the first manager's configuration is the thing to fix. Stop the extra daemon before changing anything else, or the next test measures both of them at once.

The plugin question is about the editor, too

Creating or importing a VPN connection needs the plugin that provides that connection type, and on a desktop it usually needs an editor integration as well. The service-side package can be present while the editor form is missing, which is why a menu entry can exist and still fail. Check both halves against the distribution's packaging rather than assuming one package installs everything.

A standalone client binary is not evidence either. Installing an OpenVPN binary does not by itself give the desktop editor a form for creating an OpenVPN profile.

Correct the responsible boundary, then verify

Once you know which boundary is wrong, change only that one. Marking a device managed, granting a permission, or installing an editor package are three different operations with three different risk profiles, and mixing them makes the result impossible to attribute. If ownership has to move, do it with console or out-of-band access available, because a mistake there can remove the network you are using to fix it.

Then verify with the real account and the real profile: confirm the route, the DNS view, and where the secret is stored. Enabled buttons are an interface state, not proof that a tunnel works. Record the device state, the permission answer, and the plugin version in the ticket, so the next person knows which boundary actually changed.