How to Fix Netplan Changes Not Applying After Editing YAML

You edited the Netplan YAML file carefully, saved it, ran apply, and nothing changed. The server still has the old address, or it came back after a reboot, yet Netplan reported no error. In practice, Netplan changes fail for a small set of repeatable reasons: a YAML spacing error, the wrong file, file permissions, a second file overriding yours, cloud-init rewriting the config, or the old address staying as a secondary address. This guide works through those causes in order.

Quick Answer

Run sudo netplan generate to uncover YAML errors, confirm you edited the live file in /etc/netplan/ with correct spaces and permissions, then run sudo netplan apply. If settings return after reboot, check for a second Netplan file or cloud-init overwriting your file, and check ip a carefully because the old address may be lingering alongside the new one.

How to Think About a Netplan Failure

When you run apply, Netplan reads every .yaml file in /etc/netplan/ in filename order, generates backend files, and tells systemd-networkd or NetworkManager to use them. A failure can happen at any stage, and each stage leaves a different clue.

If generate reports an error, the problem is inside the file: spelling, indentation, or an outdated key. If generate is silent but apply changes nothing, you may be editing the wrong file or another file is winning. If apply works but a reboot undoes it, something is regenerating the file, most often cloud-init. If the new address appears but the old one is still there, DHCP may still be on.

Run the checks below in sequence and let each result point to the next step, instead of changing five things at once.

Step 1: Run Netplan Generate and Read the Error Properly

1. Run sudo netplan generate and read the full output, including the line and column numbers it gives you.
2. Run sudo netplan apply and watch for warnings about permissions, deprecated keys, or invalid addresses.
3. For more detail, run sudo netplan --debug apply on a test system, or check recent system messages with sudo journalctl -u systemd-networkd -n 50.
4. Open the file at the exact line mentioned and compare its indentation with the lines above and below it.
5. Fix one error, save, and run generate again. YAML errors are often reported one at a time.

The most common file errors are tab characters instead of spaces, a missing colon, a misaligned list dash, and a misspelled key or interface name. Check for hidden tabs with cat -A /etc/netplan/50-cloud-init.yaml. Tabs show as ^I. If you see them, rewrite those lines using spaces only.

Step 2: Confirm You Edited the File Netplan Actually Loads

It sounds obvious, but this catches many people. You may have edited a copy in your home folder, a backup, or a file on a different machine through an old SSH session.

1. List what Netplan will load with ls -l /etc/netplan/.
2. Read each live file with sudo cat /etc/netplan/*.yaml and look for your interface name in each one.
3. Check the time you last changed the file and compare it with when you thought you saved it.
4. Remove or rename stray backup files inside that folder that end in .yaml, moving them to your home folder instead, because Netplan will read them as live config.
5. Confirm the interface name in the file matches the real name shown by ip a, character for character. A file for eth0 does nothing on a machine whose interface is ens3.

Files are merged in lexical order, so 99-config.yaml can override values set in 50-cloud-init.yaml. The cleanest fix is one clear file per interface. Our companion guide on setting a static IP on Ubuntu Server with Netplan correctly shows a clean single-file layout you can compare yours against.

Step 3: Fix File Permissions and Ownership

Recent Ubuntu versions check Netplan file permissions because these files can contain secrets. If permissions are too open, Netplan may warn and, in some setups, refuse to proceed as you expect.

1. Check permissions with ls -l /etc/netplan/.
2. Set the main file to root-only read and write with sudo chmod 600 /etc/netplan/50-cloud-init.yaml, using your real filename.
3. Confirm ownership is root with sudo chown root:root /etc/netplan/50-cloud-init.yaml if it has changed.
4. Run sudo netplan generate again and confirm the permissions warning has gone.
5. Then run sudo netplan apply again and verify with ip a.

Step 4: Use the Modern Keys and Remove Deprecated Ones

A file copied from an old tutorial may still use settings that current Netplan no longer wants. The biggest example is gateway4, which is deprecated. Another is mixing a renderer the server does not use.

• Replace a gateway4: 192.168.1.1 line with a routes block that sets to: default and via: 192.168.1.1.
• Make sure each address includes its prefix, such as 192.168.1.50/24, not a bare address.
• If you want DHCP off, the file must say dhcp4: false clearly under the correct interface.
• Remove duplicate gateway, DNS, or address blocks left over from an earlier edit.
• Check the renderer. Ubuntu Server normally uses networkd. Do not add a NetworkManager renderer line copied from a desktop guide unless your system actually uses it.

The official Netplan YAML reference lists the current keys and examples, and the Netplan examples page with common configurations is useful for comparing your file against a known working layout for a static address, a DHCP address, and Wi-Fi.

Step 5: Stop Cloud-Init From Rewriting Your File

If your change applies perfectly, works all day, and vanishes after a reboot, look at the top of the file. Many installer-generated files begin with a comment saying the file was generated by cloud-init and will not persist across an instance reboot unless you disable the cloud-init network config.

1. Read the header with head /etc/netplan/50-cloud-init.yaml.
2. Check for the disable file approach: create /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the line network: {config: disabled}.
3. Create that folder file with sudo nano /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg, paste the line exactly, and save.
4. Re-apply your Netplan change, reboot once, and read the file again to confirm your settings survived.
5. On a cloud virtual machine, check the provider guidance first, because cloud-init may be needed for other boot tasks there.

Step 6: Check Whether the Change Applied but Looks Unchanged

Sometimes Netplan did apply, and the confusion is in how you checked. An old DHCP address can linger, DNS can be cached, or you can be connected to the old session.

• Run ip a fresh and read every address on the interface, not just the first line. A static and a DHCP address can coexist if dhcp4 was left on.
• Run ip route to see if the gateway changed as expected.
• Check DNS with resolvectl status and confirm the servers listed match your file.
• Start a brand new SSH session to the new address instead of trusting the old terminal, which is still connected to the old address.
• Restart the backend only if needed with sudo systemctl restart systemd-networkd, and understand that this will drop connections briefly.
• If a service still uses old settings, restart that service or reboot the machine once, during a safe window.

Common Mistakes and Useful Tips

• Never running generate: Apply can hide the clearest error message. Generate first, every time, until it runs silently.
• Leaving backup .yaml files in /etc/netplan: They are not backups in that folder, they are live config. Move them elsewhere.
• Mixing tutorials from different Ubuntu versions: Old keys and desktop renderer advice cause subtle failures on a 24.04 server.
• Editing while connected to the wrong machine: Check the hostname with hostname before editing any remote server.
• Changing everything at once: Fix one cause, retest, then move on. Otherwise you will not know what actually fixed it.
• Tip — use netplan try on a console: The automatic rollback protects you while you learn which part of the file was wrong.
• Tip — keep a known-good copy: Once a file works, save a dated copy outside the Netplan folder, with a note about the network it belongs to.

Conclusion

When Netplan changes do not apply, the cause is almost always findable: a YAML error shown by generate, the wrong or overridden file, loose permissions, a deprecated key, cloud-init rewriting the file at boot, or a new address hiding beside the old one. Work through generate, file list, permissions, modern keys, and cloud-init in that order, verifying with ip a after each fix. That calm sequence will restore control of your network settings without reinstalling or guessing.

Frequently Asked Questions

Why does netplan apply show no error but nothing changes?

Usually because another Netplan file overrides yours, you edited a file Netplan is not loading, or the interface name in the file does not match the real interface. List all files in /etc/netplan/, read them all, and match the interface name against ip a.

How do I know if a YAML indentation problem is my issue?

Run sudo netplan generate. If indentation or syntax is wrong, it reports the file, line, and column. Open that exact spot, ensure spaces only and consistent levels, save, and run generate again until it completes without errors.

Why do my Netplan settings disappear after every reboot?

That pattern points to cloud-init regenerating the installer file. Read the comment at the top of the file, then disable only cloud-init’s network config using the 99-disable-network-config file, re-apply your settings, and test with a reboot.

What is the difference between netplan generate, try, and apply?

Generate checks and builds the backend files without fully switching you over. Try applies the change with a timed rollback if you do not confirm. Apply makes the change immediately and permanently. Use them in that order when the change matters.