🚨 Linux Error: 'Failed to start Network Manager' — no network after netplan apply, Cause, Fix, and Troubleshooting Guide

What this error means

You apply a netplan change on Ubuntu and the host drops off the network. netplan apply may print a YAML or renderer error, or the box comes back with no address at all:

$ sudo netplan apply
/etc/netplan/01-netcfg.yaml:8:5: Invalid YAML: inconsistent indentation
Failed to start Network Manager

Netplan is a front-end, not a network stack. It reads YAML from /etc/netplan/*.yaml and renders backend config for one of two renderers: systemd-networkd (the server default) or NetworkManager (the desktop default). When the YAML is malformed, the interface name is wrong, or the renderer: points at a backend that is not installed or running, netplan generates broken (or no) config and the interface never comes up.

Because a bad apply can cut your own SSH session, netplan ships netplan try, which applies the change and automatically rolls back after a timeout unless you confirm — always prefer it on a remote host.

How it manifests on the host

• sudo netplan apply errors with Invalid YAML, inconsistent indentation, or unknown key.
• Failed to start Network Manager / Failed to start systemd-networkd in the output or journalctl.
• ip a shows the interface DOWN or with no IPv4 address after apply.
• ip route has no default route, so nothing routes off-subnet.
• The host is reachable on the console but not over SSH; a remote apply killed connectivity.
• systemctl status systemd-networkd or NetworkManager is inactive/failed.

System configuration causes

1. Invalid YAML indentation. Netplan YAML is indentation-sensitive and requires spaces (never tabs). A misaligned key or a stray tab makes the whole file unparseable.
2. Wrong renderer:. The file says renderer: NetworkManager on a server where NetworkManager is not installed (or renderer: networkd where systemd-networkd is masked), so there is no backend to bring the link up.
3. Wrong interface name. The config names eth0 but the NIC is actually ens3/enp0s3 (predictable interface names). Netplan renders config for an interface that does not exist.
4. Missing dhcp4:/addresses: — the interface is defined but given no addressing, so it comes up with no IP.
5. Wrong file permissions or a stray file. A world-readable secret warning, or a second *.yaml in /etc/netplan/ with conflicting keys, produces unexpected merged config.
6. addresses: without a CIDR prefix (e.g. 10.0.0.5 instead of 10.0.0.5/24), which netplan rejects.

Interrogating the host

Do this from the console (or a session you can afford to lose), not the SSH link you are about to reconfigure.

1. See what addressing and links actually exist right now:

   ip a
   ip route

   Note the real interface names here — they must match the YAML.

2. Validate that netplan can parse and render the YAML without applying it:

   sudo netplan generate

   This writes backend config and surfaces YAML/indentation errors without touching the live network.

3. Get verbose detail on exactly which key/line fails:

   sudo netplan --debug apply 2>&1 | less

4. Confirm which backend is expected and whether it is running:

   systemctl status systemd-networkd
   systemctl status NetworkManager
   networkctl status                      # networkd view of each link

5. Inspect the config itself (spaces only, correct nesting):

   sudo cat /etc/netplan/*.yaml

Remediation

1. Test safely with automatic rollback — this is the correct way to apply a risky change remotely. Netplan reverts after ~120s unless you press Enter to confirm:

   sudo netplan try

2. Fix the YAML. Use spaces (2-space steps), never tabs, and give addresses a CIDR prefix. A minimal, valid static config for the systemd-networkd renderer:

   network:
     version: 2
     renderer: networkd
     ethernets:
       ens3:
         dhcp4: false
         addresses:
           - 10.0.0.5/24
         routes:
           - to: default
             via: 10.0.0.1
         nameservers:
           addresses: [10.0.0.2, 1.1.1.1]

   Replace ens3 with the interface name from ip a.

3. Match the renderer to what is installed. On a headless server use renderer: networkd and make sure the service is enabled:

   sudo systemctl enable --now systemd-networkd

   If you truly want NetworkManager, install and enable it before selecting it:

   sudo apt-get install -y network-manager
   sudo systemctl enable --now NetworkManager

4. Correct the interface name in the YAML to the real device from ip a (e.g. ens3, enp0s3, eth0). A DHCP-only interface is simply:

   network:
     version: 2
     renderer: networkd
     ethernets:
       ens3:
         dhcp4: true

5. Regenerate and apply once the file validates:

   sudo netplan generate
   sudo netplan apply

   Warning: netplan apply takes effect immediately and can drop your SSH session on a bad config. Prefer netplan try for remote hosts, and keep console/out-of-band access available.

Hardening the host

• Tabs break netplan. YAML forbids tabs for indentation — if your editor inserted one, apply fails with an indentation error even though the file “looks” right.
• addresses: needs a CIDR prefix (/24, /32, etc.). A bare IP is rejected.
• Interface names are not always eth0. Cloud and modern hardware use predictable names like ens3/enp0s3. Always copy the name from ip a.
• A netplan apply on a live remote box is risky. Use netplan try so a mistake auto-reverts instead of locking you out.
• Multiple files in /etc/netplan/ merge. A leftover 50-cloud-init.yaml can override your file; check every *.yaml present.
• Netplan warns if a config file is world-readable and contains secrets — set sudo chmod 600 /etc/netplan/*.yaml.

Related system errors

• Linux Error: Network is unreachable
• Linux Error: Temporary failure in name resolution
• Configuring Static and Dynamic Networking with systemd-networkd

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.