Call for testing: NetworkManager YAML settings

Hello folks,

This is Lukas Märdian, a software engineer for the Ubuntu Foundations team. I have been working on integrating NetworkManager’s settings plugin with Netplan’s YAML schema, using libnetplan. We’d like to ask the community to help test our prototype of this integration on a wide variety of networking setups.

Rationale and background information is the “single source of truth” for controlling Ubuntu’s networking stack, i.e. you can find all the information about your network configuration in /etc/netplan/ (or using sudo netplan get) on Ubuntu Server, Ubuntu Cloud images, Ubuntu Core IoT, etc …
On Ubuntu Desktop OTOH we’re deviating a bit from this approach, as NetworkManager instead stores its “keyfile” settings in /etc/NetworkManager/system-connections/.
This is what we want to unify!

In the past, Netplan used a mostly single-sided “generator” approach, i.e.

  1. setup your configuration in /etc/netplan/ (or using sudo netplan set)
  2. call netplan apply to generate settings and configure the backend(s), like systemd-networkd, NetworkManager, Open vSwitch, …

This is now changing as NetworkManager on Ubuntu Desktop needs to be able to feed back information to Netplan’s YAML config (e.g. a WiFi password that was changed in NetworkManager’s settings UI). Therefore, we need a bidirectional integration where NetworkManager can talk to Netplan and vice versa.

How do you feel about NetworkManager’s YAML backend?
  • Works great, I like!
  • Meh.
  • Boo!

0 voters

Backup, Setup (& Recovery)

WARNING: Always backup your NetworkManager “keyfile” connection profiles from /etc/NetworkManager/system-connections/ and the original .deb packages. In case something goes wrong, you want to be able to roll back those settings. And remember you might need to do that offline, if networking is broken:

$ mkdir ~/NetworkManager.bak && cd ~/NetworkManager.bak/
$ sudo cp -r /etc/NetworkManager/system-connections .
## Download current NetworkManager version .deb packages
$ apt download gir1.2-nm-1.0 libnm0 network-manager network-manager-config-connectivity-ubuntu
$ ls -la . # check backup

Note: NetworkManager will automatically create backups of your original keyfiles on upgrade and strore them in /root/NetworkManager.bak/

Next, install NetworkManager packages from the Netplan Everywhere PPA for Ubuntu “Jammy” 22.04 LTS or above:

$ sudo add-apt-repository ppa:canonical-foundations/networkmanager-netplan
$ sudo apt update
$ sudo apt install network-manager
$ apt list network-manager # check version (should contain "netplan")
Offline recovery (in case something goes wrong)
$ cd ~/NetworkManager.bak
$ sudo rm -r /etc/NetworkManager/system-connections
$ sudo cp -r ./system-connections /etc/NetworkManager/
$ sudo find /run/NetworkManager/system-connections/ -name "netplan-*.nmconnection" -exec rm {} \;
$ sudo find /run/NetworkManager/system-connections/ -name "*.nmmeta" -exec rm {} \;
$ sudo rm /etc/netplan/90-NM-*.yaml
$ sudo netplan generate
## Reboot or continue below with full roll-back

If you want to fully roll-back, continue with:

$ sudo rm /etc/apt/sources.list.d/canonical-foundations-ubuntu-networkmanager-netplan-*.list
$ sudo dpkg -i *.deb # install local, original NetworkManager .deb packages
$ sudo apt update
$ sudo systemctl restart NetworkManager.service

Test plan

Whenever you add, modify or delete a connection in NetworkManager (e.g. via settings UI, D-Bus API, nmcli, …) it will be reflected in Netplan’s YAML configuration (i.e. sudo netplan get).

Below we list a few common cases for testing the NetworkManager + Netplan settings backend integration, as well as some inspiration for additional test cases.

Common case 1: Ethernet Connection

Check /etc/netplan for a .yaml file that already contains an ethernet connection and remove it. Then connect your system to a live ethernet connection via NetworkManager and check for the corresponding YAML to be created and make sure the contents look correct.

$ grep -ri ethernet /etc/netplan
/etc/netplan/90-NM-1b0dfe3a-2815-36aa-8e48-f883bbf16829.yaml:  ethernets:
/etc/netplan/90-NM-1b0dfe3a-2815-36aa-8e48-f883bbf16829.yaml:          ethernet._: ""
$ rm /etc/netplan/90-NM-1b0dfe3a-2815-36aa-8e48-f883bbf16829.yaml

## Plug into ethernet
$ cat /etc/netplan/90-NM-1b0dfe3a-2815-36aa-8e48-f883bbf16829.yaml
  version: 2
      renderer: NetworkManager
        name: "enp0s31f6"
      dhcp4: true
      dhcp6: true
      ipv6-address-generation: "stable-privacy"
      wakeonlan: true
        uuid: "1b0dfe3a-2815-36aa-8e48-f883bbf16829"
        name: "Wired connection 1"
          connection.autoconnect-priority: "-999"
          connection.timestamp: "1662490134"
          ethernet._: ""
          ipv6.ip6-privacy: "-1"
          proxy._: ""
          .nmmeta.nm-generated: "true"

Common case 2: Wifi Connection

Using nmcli, create a new connection and look for an equivalent change under /etc/netplan/

$ nmcli con add con-name wifi1 type wifi ifname wifi1 ipv4.method manual ipv4.address ipv4.gateway ssid <ssid_name>

## should show your new wifi connection
$ nmcli con show
NAME         UUID                                  TYPE  DEVICE 
XXXXX        dffebd3b-f21e-4e0f-9ca0-59667d6ac3ac  wifi  wlp1s0 
XXXXX        ac0346ad-08f0-48d6-a071-11c7631d4374  wifi  --     
wifi1        f7adb62a-8088-4270-ac09-10755064cbb3  wifi  --

## Note there is a 90-NM-dffebd3.. for another wifi network that I've connected to
$ ls -l /etc/netplan 
total 12
-rw-r--r-- 1 root root 104 Apr 19 04:09 01-network-manager-all.yaml
-rw-r--r-- 1 root root 705 Sep 14 16:43 90-NM-dffebd3b-f21e-4e0f-9ca0-59667d6ac3ac.yaml
-rw-r--r-- 1 root root 676 Sep 12 15:28 90-NM-f7adb62a-8088-4270-ac09-10755064cbb3.yaml

See the new YAML file listed and open it up to look and make sure it looks correct

$ cat /etc/netplan/90-NM-f7adb62a-8088-4270-ac09-10755064cbb3.yaml
  version: 2
      renderer: NetworkManager
        name: "wifi1"
      - ""
      dhcp6: true
      ipv6-address-generation: "stable-privacy"
            uuid: "f7adb62a-8088-4270-ac09-10755064cbb3"
            name: "wifi1"
              ipv4.address1: ","
              ipv4.method: "manual"
              ipv6.ip6-privacy: "-1"
              proxy._: ""
        uuid: "f7adb62a-8088-4270-ac09-10755064cbb3"
        name: "wifi1"

Insipration for further testing

In addition to standard WiFi and ethernet connections, we’d like to ask the community to test a wide variety of networking setups, as we cannot reproduce all the different setups that any of you might encounter in their daily lifes. Including, but not limited to:

  • Enterprise WiFi (e.g. eduroam)
  • WWAN (gsm/cdma modem connections)
  • WiFi AP mode (Fat, Fit, Cloud - and switching between them)
  • Different types of VPN connections (IPSec, WireGuard, VPNC, …)
  • Composite devices, like bridges or bonds
  • Virtual VLAN and Tunnel devices
  • DHCP address assignment (both IPv4 and IPv6)
  • Static IP assignment (both IPv4 and IPv6)
  • Shared network connectivity, e.g. a connection created with:
    nmcli c add con-name shared type ethernet ifname enx000ec6e241bf ipv4.method shared ipv6.method ignore


Please let us know about your experience using the NetworkManager+Netplan prototype, be it positive or negative. Your feedback is highly appreciated! Try to describe the setup you’ve been testing in detail and present any problems that might have occurred.

Errata (Things already known to be problematic):

  • Connections that rely on an additional NetworkManager plugins (e.g. network-manager-vpnc)

It’s appears to work fine. An interesting side effect is that my wifi worked automatically in my NetworkManager + iwd setup.


Could we consider instead going all-NetworkManager instead? NetworkManager is fully capable of handling all the various networking cases we care about, and recently cloud-init got support for generating native NetworkManager keyfiles too.

This would also align us with other distributions (RH/Fedora, [open]SUSE) and let us benefit from the shared development going on in NetworkManager for all these use-cases.


Worked fine here. My setup:

  1. ethernet card
  2. wifi
  3. a handful of OpenVPNs

All got correctly reflected both ways, only spewed warnings all over, but that’s probably by design.

netplan: NM-…: handling NetworkManager passthrough device, settings are not fully supported.

One thing that was unexpected, though — in your “Common case 1”, when I removed the Ethernet connection and sudo netplan apply'd, NM reconnected to the wired network immediately, but netplan was unawares. Only after dis- and reconnecting the cord did things show up.


Actually there’s one issue I found. I had a custom route added to an OpenVPN connection:


I can’t get that back with the new setup. Even adding the below to the yaml doesn’t help. It may well be a NM bug, as I was only able to get this behaviour (a gateway-less route configuration) in NM through manual editing of the connection files.

  ipv4.route1: ","

Some issues using the network-manager-openvpn plugin have been reported by @alfonsosanchezbeato in LP#1998207

While writing an autopkgtest for this integration I believe I’ve found another issue. After creating a connection, the file is created in /etc/netplan, but then I try to change it hoping that Network Manager would apply the changes to the existing file. But it ends up deleting both the Netplan and the keyfile files while the connection will still exist.

I’ve created a script that can be used to reproduce the issue.

I just tried this on Lubuntu Lunar.

Some things I noticed:

1: After installing the Netplan-integrated NetworkManager, my WiFi and loopback connections appeared to drop, then both reconnected. WiFi dropping out seems normal, however I don’t think the loopback connection should ever drop. Not sure if that’s something to be taken into account.

2: When installation was finished, sudo netplan get and ls /etc/netplan both showed almost no Netplan-related data. All I got from sudo netplan get was:

    ** (process:4088): WARNING **: 12:41:41.394; Permissions for /etc/netplan/01-network-manager-all.yaml are too open. Netplan configuration should NOT be accessible by others.
      version: 2
      renderer: NetworkManager

I had to disconnect from WiFi, entirely delete my WiFi connection with nmtui, then reconnect to WiFi in order to get anything to register in Netplan. After doing that, things seem to look normal.

3: Netplan is storing my WiFi password in cleartext. I don’t think this is a problem since the .yaml file that actually holds my WiFi info isn’t publicly accessible like the 01-network-manager-all.yaml file is. However, I believe that Kubuntu (at least sometimes) holds the WiFi password in KWallet, and retrieves it from KWallet to connect to WiFi. I’m wondering how that will interact with Netplan - will the two conflict? Will one get ignored?

4: Last but not least since this ended up not being a bug, it looks like Netplan is failing to get the IP address from NetworkManager. My sudo netplan get output looks like this after getting things to show up there:

  version: 2
  renderer: NetworkManager
      renderer: NetworkManager
         name: "wlp1s0"
      dhcp4: true
      dhcp6: true
        "My WiFi Hotspot Name":
            key-management: "psk"
            password: hunter2
            uuid: "90ea9018-baa8-41d5-8c59-f4044a9c8b31"
            name: "My WiFi Hotspot Name"
              wifi-security.auth-alg: "open"
              ipv6.addr-gen-mode: "default"
              ipv6.ip6-privacy: "-1"
              proxy._: ""
        uuid: "90ea9018-baa8-41d5-8c59-f4044a9c8b31"
        name: "My WiFi Hotspot Name"

The “Common case 2: Wifi Connection” above shows that there are IPv4 addresses in the Netplan output, and I know my hotspot provides me an IPv4 address.

My WiFi appears to be working just fine, though - I can still browse websites and whatnot without problems so far.

My testcase is a fairly standard WiFi connection on a laptop. I’m using a cellular WiFi hotspot. Also, in case it wasn’t obvious, “My WiFi Hotspot Name” is not the actual name of my WiFi hotspot, and “hunter2” is not my actual WiFi password.


I filed a new bug about the missing IPv4 information here: (edit - not a bug, I misunderstood how this was supposed to work.)


I noticed the same behaviour. In my case, I tested with an eduroam connection.
Having the password show in plain-text in the netplan yaml is definitely not ideal, especially for connections like eduroam or corporate WiFi where it’s possible the users domain username/password is used for eduroam authentication.
Worse still because all netplan yaml files are world-readable.

Although, this might also be the case with NetworkManager system-connection files??

Some more notes from my eduroam connection testing.

Adding the eduroam connection with nmcli command seems to always fail with the following error:

Error: Failed to add 'eduroam' connection: failure adding connection: settings plugin does not support adding connections

Adding with the GNOME control center GUI appears to work, and I get a corresponding file in /etc/netplan/90-NM*****.
However, the new netplan isn’t automatically applied for me, and even after a netplan apply, the new eduroam connection doesn’t show for me.

This should actually not be the case. The NetworkManager-Netplan integration is supposed to create files accessible to root only, using “0o600” permissions (-rw-------). Can you please double-check your system for the file permissions:

$ ls -la /etc/netplan/
$ sudo ls -la /run/NetworkManager/system-connections/

Thanks a lot for reporting this issue! Can you please elaborate on this issue: which nmcli command are you using exactly? How to reproduce it? Could you maybe create a bug report about this at OpenID transaction in progress giving all the details?

Thank you very much for your tests and bug reports @arraybolt3! This is very helpful.
A new version is now deployed to the PPA (for Lunar), which should migrate all of the existing connection profiles in /etc/NetworkManager/system-connections to /etc/netplan on upgrade/install. Could you give this another try?

1 Like

Sorry for the delay. Only just got a chance to revisit this.

Here’s the output of those commands: ls -l /etc/netplan/
total 8
-rw-r--r-- 1 root root  813 Apr 17 12:32 90-NM-d7129202-78f4-4651-a606-f91cda2a75b7.yaml
-rw-r--r-- 1 root root 1272 Apr  5 15:59 99-ebi-netplan.yaml ls -la /run/NetworkManager/system-connections/
total 16
drwx------ 2 root root 120 Apr 17 12:32 .
drwx------ 5 root root 140 Apr 17 12:07 ..
-rw------- 1 root root 477 Apr 17 12:32 netplan-EBI-WIFI-EBI.nmconnection
-rw------- 1 root root 432 Apr 17 12:32 netplan-EBI-WIRED.nmconnection
-rw------- 1 root root 287 Apr 17 12:32 netplan-NM-d7129202-78f4-4651-a606-f91cda2a75b7-eduroam.nmconnection
-rw------- 1 root root 143 Apr 17 12:32 netplan-Standard.nmconnection

90-NM-d7129202-78f4-4651-a606-f91cda2a75b7.yaml is the yaml file automatically created when attempting to add eduroam via nmcli.
The other netplan yaml file is one we deploy ourselves.

I’ve submitted a bug for this with the relevant details:

1 Like


Thank you for your great work on Netplan, it keeps getting more useful every day.

Being a user of the Ubuntu development release (Mantic), my system got migrated as a part of the updated network-manager package. Most of my connections appear to have migrated smoothly, but one of them resulted in a failure:

Setting up network-manager (1.42.4-1ubuntu3) ...
Migrating Bridge connection 1 (505dd778-c585-4632-bad2-70ac6964fcfc) to /etc/netplan
Error: Failed to modify connection 'bridge0 port 1': Message recipient disconnected from message bus without replying
FAILED. Restoring backup ...

Looking at the pieces the migrated bridge looks like this:

sudo cat /etc/netplan/90-NM-505dd778-c585-4632-bad2-70ac6964fcfc.yaml 
  version: 2
      renderer: NetworkManager
      dhcp4: true
      dhcp6: true
      ipv6-address-generation: "stable-privacy"
        uuid: "505dd778-c585-4632-bad2-70ac6964fcfc"
        name: "Bridge connection 1"
          connection.timestamp: "1684472567"
          ethernet._: ""
          bridge._: ""
          ipv6.ip6-privacy: "-1"
          proxy._: ""

And the port in that bridge that it complained about appears to still be in NM-format:

$ sudo cat /etc/NetworkManager/system-connections/bridge0\ port\ 1.nmconnection
id=bridge0 port 1



Should I report a LP bug for this?

Thanks a lot for providing feedback here, Frode!

Yes, please open a bug report at OpenID transaction in progress providing the original keyfile, the generated (corrupt?) YAML, tagging it netplan-everywhere.


See latest updates in [Blog] Netplan developer diaries
This intergration is now enabled in Ubuntu Mantic.

Is there a way to go without the netplan integration in Ubuntu 23.10 ??
I really dont like it - so I banned netplan package with a empty dummy package.

But I cant create new network connections:

Nov 13 22:46:10 ub-tc NetworkManager[1007]: <info>  [1699911970.3108] audit: op="connection-add-activate" pid=2062 uid=1000 result="fail" reason="failure adding connection: settings plugin does not support adding connections"

I hope you guys also come up with a simple disable plugin or whatever config line for NetworkManager to let ppl choose not to migrate to netplan backend!

By force was newer a good choice :roll_eyes: