Read the D-Bus Model Behind a NetworkManager Profile

Every property nmcli lets you touch lives in a D-Bus settings object underneath, and that model explains why some "obvious" edits silently do nothing. This guide inspects a profile, changes one ordinary setting, verifies the stored value, and restores it when done. 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 you are allowed to edit. This is a configuration task, not a D-Bus programming tutorial: the manual describes the model behind the profile, a connection has a UUID and contains named groups of key/value settings, and nmcli is the practical way to read and change 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 mean 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      --

Those names and UUIDs are examples; your output may include 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 check, ask only for the fields the decision actually needs:

$ 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 sets the default for connection.autoconnect to true and the default priority to 0. Autoconnect is conditional: it does not compete with an already active profile, and a higher priority wins among candidates. Equal priorities are resolved by recent use, so changing priority is a policy choice, not a cosmetic label.

• A default-looking value can mean "consult a global default" instead. 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 guess.
• Missing property? Stop. Check its spelling with nmcli connection show "$PROFILE" rather than substituting 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. It matters because restoring "the default" is not always the same as restoring the value that was actually 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 stays active until it is explicitly brought down or replaced. The changed setting only 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

Those two checks answer different questions: the first confirms the profile value, the second shows what is active right now. A profile can be active while its autoconnect value is no. Do not run nmcli connection down or nmcli connection up just to make the output look consistent; either can interrupt traffic.

5. Restore the previous value

When the test is over, restore the value you recorded. This 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 the initial inspection showed and confirm the result afterwards; do not assume an empty value and -1 mean the same thing.

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, not a string you pass as a setting key.
• Changing a read-only value. Some properties, such as observed Wi-Fi BSSIDs, are maintained by NetworkManager itself 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 edit.