Inspect Merged Netplan YAML with netplan get

You will use netplan get to see the effective Netplan configuration, extract one setting, and diagnose a bad YAML file without applying any network change. This guide follows the netplan.io version installed here, 1.1.2-8ubuntu1~24.04.3. Allow about five minutes for a read-only inspection.

You need a shell and Netplan installed. The normal command only reads configuration, so start without sudo. Use elevated privileges only if the files are unreadable to your account. Nothing in this guide runs netplan apply, netplan try or netplan set.

1. Confirm the command and syntax

Check the installed binary and the command-specific help before copying a key from an old example:

$ command -v netplan
/usr/sbin/netplan
$ dpkg-query -W -f='${Package} ${Version}\n' netplan.io
netplan.io 1.1.2-8ubuntu1~24.04.3
$ netplan get --help
usage: /usr/sbin/netplan get [-h] [--debug] [--root-dir ROOT_DIR] [key]

The command is a subcommand of netplan, not a separate executable you normally invoke as netplan-get. The key is optional. all is the documented name for the complete tree and is also the default when you omit the key.

2. Print the effective configuration

Read the complete merged tree with:

$ netplan get all

The output is YAML written to standard output. On a host with a simple Ethernet definition, the shape will resemble this, although device names and values are host-specific:

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true

The command reads matching YAML files from /etc/netplan, /lib/netplan and /run/netplan and presents their merged state. Files with different names are processed in lexicographical order. A later scalar replaces an earlier scalar, mappings are merged by key, and sequences are appended. A file in a higher-priority directory with the same name shadows the lower-priority copy. This is why the result may differ from any one file you opened.

Keep the output private when it contains addresses, routes, wireless settings or other operational details. The command does not redact them.

3. Query one branch or value

Use a dotted key to reduce the output while investigating one interface:

$ netplan get network.ethernets.enp1s0
dhcp4: true
$ netplan get ethernets.enp1s0.dhcp4
true

The leading network. is accepted, and the shorter path is useful for the common device groups. Replace enp1s0 with the exact ID shown by your full output. Do not assume that an interface's kernel name is its Netplan ID, especially for bridges, bonds and Wi-Fi definitions.

4. Test a configuration copy with --root-dir

--root-dir makes Netplan look below another root instead of the real filesystem root. This is useful for a staging directory or a test fixture and avoids reading the host configuration:

$ netplan get --root-dir /path/to/staging-root all
network:
  version: 2
  ethernets:
    TEST_INTERFACE:
      dhcp4: true

The directory must contain the expected layout, such as /path/to/staging-root/etc/netplan/*.yaml. Keep TEST_INTERFACE as a placeholder in copied examples: replace it with an actual Netplan ID in a real fixture. A read-only inspection of a fixture needs no elevated privileges if your account can read the fixture.

For a safe fixture, make a new directory and files rather than pointing --root-dir at a live system tree you did not intend to inspect. This option changes where the command reads; it does not create a configuration and it does not apply one.

5. Turn on diagnostics when parsing is unclear

Prepend the global --debug option when you need Netplan's processing messages:

$ netplan --debug get --root-dir /path/to/staging-root all
... DEBUG ... Configuration is valid
network:
  version: 2
  ethernets:
    TEST_INTERFACE:
      dhcp4: true

The exact timestamps and diagnostic lines vary. Look for the final configuration message and the YAML output, not for a fixed line number. Debug output is normally sent to standard error while the YAML remains suitable for capture on standard output.

Do not mistake a successful read for a successful network deployment. netplan get parses and prints state. It neither generates backend files nor changes the running network.

6. Separate missing data from invalid YAML

A missing dotted key is not necessarily an error on this installed version. In an isolated valid tree, a query for an absent branch prints null and returns status 0:

$ netplan get --root-dir /path/to/staging-root ethernets.DOES_NOT_EXIST
null
$ printf 'status: %s\n' "$?"
status: 0

Check the complete tree before concluding that a device is absent. A typo can look like a valid empty result.

Malformed YAML is different. Netplan reports the file and parse location and returns non-zero:

$ netplan get --root-dir /path/to/staging-root all
Command failed: /path/to/staging-root/etc/netplan/99-bad.yaml:3:1: Invalid YAML: did not find expected ',' or ']'
$ printf 'status: %s\n' "$?"
status: 1

Fix the named file only after reviewing the change and preserving a copy. Do not run a broad replacement across /etc/netplan; filenames, ordering and duplicate keys can affect the merged result. If you must edit live configuration, use your change-control and rollback process, then validate with netplan get before any separate apply step.

7. Avoid the common inspection traps

Do not use netplan get as a substitute for netplan status. The former reads declared YAML; it does not prove that the running interface has the requested address or that a backend accepted the configuration. Conversely, a setting missing from get may be supplied by another layer outside Netplan, so investigate the running state separately.

If the command reports permission errors, inspect file ownership and mode first. Retry with sudo netplan get all only when your policy permits it. Elevated access can make a read succeed, but it does not repair malformed YAML or create a missing key. Never paste the complete output into a public issue without removing secrets and network details.