Comment 6 for bug 1959570

I do not yet fully understand what's going on here.

The 'nmcli' command is exported from the network-manager snap and can be called from the shell without a problem. So I have the impression that for some reason the call stack/execution environment is different here.

AFAIU "snap set" drives netplan, using its DBus API, so is calling "io.netplan.Netplan.Try/Apply" eventually. This will automatically start the "netplan-dbus" process, which will spawn the "netplan apply" command.

The "netplan apply" command has some special case logic if execute inside a snap (detected by reading the "SNAP" environment variable), if inside a snap, it will re-execute itself, using the o.netplan.Netplan.Apply DBus API, in order to "break" out of the snap confinement and be executed in the Core20/22 root system.

=> See we might have an infinite loop here, if the SNAP environment variable is not detected/passed correctly.

When the "netplan apply" command is excuted outside a snap in the Core20/22 base system, it will apply its changes and restart systemd-networkd.service and NetworkManager.service (or the respecitive service that is provided by the network-manager snap) and call into "nmcli" to wait for it to be ready.

For some reason it seems to be unable to find the "nmcli" binary in its PATH, so my assumption is that it is not able to break out of the snap, but rather is executed within the snapd snap's confinement.

This needs more investigation to fully understand what's going on.