Inspect and Safely Tune NetworkManager Profiles with nmcli

You will inspect a NetworkManager connection profile, change one ordinary setting, verify the stored value, and restore it when finished. The examples use NetworkManager and nmcli 1.46.0, matching the installed nm-settings-dbus(5) manual. Allow about fifteen minutes. You need a shell and a profile that you are allowed to edit.

This is a configuration task, not a D-Bus programming tutorial. The manual describes the D-Bus model behind the profile: a connection has a UUID and contains named groups of key/value settings. nmcli is the practical interface for reading and changing those same properties.

1. Identify the profile before editing it

Start without sudo. List the profiles and copy the exact name of the one you intend to inspect:

$ nmcli -f NAME,UUID,TYPE,DEVICE connection show
NAME             UUID                                  TYPE      DEVICE
Office ethernet  11111111-2222-3333-4444-555555555555  ethernet  enp1s0
Lab Wi-Fi        66666666-7777-8888-9999-aaaaaaaaaaaa  wifi      --

The names and UUIDs above are examples. Your output may contain inactive profiles with an empty device column. Treat the UUID as the reliable identity when names are similar. Set a shell variable using your real profile name, keeping the quotes:

$ PROFILE='Office ethernet'
$ nmcli connection show "$PROFILE"

The second command prints the profile's settings, including sections such as connection, 802-3-ethernet or 802-11-wireless. Reading a profile does not activate it or alter its stored configuration.

2. Read the relevant property

Properties are addressed as setting.property. For a general profile check, ask only for the fields needed for the decision:

$ nmcli -g connection.id,connection.uuid,connection.type,connection.autoconnect,connection.autoconnect-priority connection show "$PROFILE"
Office ethernet
11111111-2222-3333-4444-555555555555
802-3-ethernet
yes
0

The D-Bus manual calls the default for connection.autoconnect true and the default priority 0. Autoconnect is conditional: it does not compete with an already active profile, and a higher priority wins when several profiles are candidates. Equal priorities are resolved by recent use, so changing priority is a policy choice, not a cosmetic label.

A value that looks like a default can also mean "consult a global default". This is common for integer settings whose sentinel is -1, including several DNS and retry properties. Check the property's description in nm-settings-dbus(5) before replacing a sentinel with a guessed value. If a property is not present in the output, stop and check its spelling with nmcli connection show "$PROFILE"; do not substitute a similarly named key.

Checkpoint: record the value you will restore

Write down the current value before changing anything. For this example, record yes or no from the preceding command. This matters because restoring "the default" is not always equivalent to restoring the value that was present on this profile.

3. Disable autoconnect for this profile

Use an ordinary user shell if your account can edit the profile. Otherwise, run only the modification with sudo if your distribution's policy requires it:

$ nmcli connection modify "$PROFILE" connection.autoconnect no
$ nmcli -g connection.id,connection.autoconnect connection show "$PROFILE"
Office ethernet
no

connection modify changes the stored profile. It does not mean "disconnect now". An already active connection normally remains active until it is explicitly brought down or replaced. The changed setting affects later autoconnect decisions.

4. Verify the stored and active state

Check the stored profile first, then inspect active connections separately:

$ nmcli -f connection.id,connection.autoconnect connection show "$PROFILE"
connection.id:                          Office ethernet
connection.autoconnect:                 no
$ nmcli -f NAME,DEVICE,TYPE connection show --active
NAME             DEVICE  TYPE
Office ethernet  enp1s0  ethernet

These checks answer different questions. The first confirms the profile value. The second shows what is active now. A profile can be active while its autoconnect value is no. Do not run nmcli connection down or nmcli connection up merely to make the output look consistent; those commands can interrupt traffic.

5. Restore the previous value

When the test is over, restore the value you recorded. The following example restores the documented original value yes:

$ nmcli connection modify "$PROFILE" connection.autoconnect yes
$ nmcli -g connection.autoconnect connection show "$PROFILE"
yes

If the original value was no, restore no. If it was an unset or sentinel value, use the exact form shown by the initial inspection and confirm the result afterwards. Do not assume that an empty value and -1 have the same meaning.

Common traps

• Wrong profile: names are not unique enough for guesswork. Compare the UUID and type before editing.
• Confusing D-Bus paths with property names: /org/freedesktop/NetworkManager/Settings/<num> identifies an exported profile object. It is not the string to pass as a setting key.
• Changing a read-only value: some properties, such as observed Wi-Fi BSSIDs, are maintained by NetworkManager and are not persistent user configuration. Leave them alone.
• Assuming every setting applies everywhere: the manual lists all available settings, but a property only makes sense for compatible connection types. A Wi-Fi property does not configure an Ethernet profile.
• Using root by reflex: inspection is normally unprivileged. Elevate only when the local authorisation policy rejects the specific profile edit.