Rocky 10: why your nmcli change did nothing — modify versus reapply

Test scope

A Rocky Linux 10.2 Server VM with NetworkManager 1.56.0-1.el10.

Everything runs on a dummy interface — no hardware needed and no risk to the SSH path. Screenshot: public/evidence/nmcli/rocky-reapply.png.

modify does not touch the running state

before:                                  10.97.0.1/24
$ nmcli connection modify lab-c ipv4.addresses 10.97.0.9/24
after modify (not applied yet):          10.97.0.1/24
$ nmcli device reapply dummy0
after reapply:                           10.97.0.9/24

Those three lines are the whole story:

• nmcli connection modify writes the profile storage only;
• the live interface does not change;
• nmcli device reapply pushes the new values without tearing the link down (gentler than connection up).

reapply versus up

Operation	Drops the link	Use
nmcli connection modify	no, and no effect either	stage a change
nmcli device reapply <dev>	no (for supported properties)	apply address/DNS/route changes now
nmcli connection up <name>	yes, rebuilds the connection	when reapply refuses the property

Some properties (ipv4.method switching manual ↔ dhcp, for example) cannot be reapplied and require reactivation.

List properties need + and -

$ nmcli connection modify lab-c ipv4.dns ''
$ nmcli connection modify lab-c +ipv4.dns 192.168.2.241
$ nmcli connection modify lab-c +ipv4.dns 1.1.1.1
$ nmcli -g ipv4.dns connection show lab-c
192.168.2.241,1.1.1.1
$ nmcli connection modify lab-c -ipv4.dns 1.1.1.1
$ nmcli -g ipv4.dns connection show lab-c
192.168.2.241

A plain nmcli connection modify lab-c ipv4.dns 1.1.1.1 replaces the whole list — the most common slip with multi-value properties.

Reading autoconnect-priority

$ nmcli connection modify lab-c connection.autoconnect-priority 50
$ nmcli -f NAME,AUTOCONNECT,AUTOCONNECT-PRIORITY connection show | grep lab-c
lab-c  yes  50

When several profiles with autoconnect yes target one device, the higher value wins (default 0, negatives are lower). It only influences automatic selection when the device becomes available, not a manual up.

When up is unavoidable

• Changing ipv4.method (manual ↔ auto);
• Changing connection.type or the device binding;
• Any reapply that reports it needs reactivation.

Verify by comparing ip addr with nmcli -g after the reapply; if they differ, run up once.

Common traps

• Testing the network right after modify: nothing was applied, so the command looks broken;
• Parsing -g output as a table: -g prints values only; use -f for tables;
• Replacing the DNS list by accident: forgot +;
• Reapplying an address change on ens18 over SSH: expect a brief interruption; have out-of-band access first.

Practice: see the modify/reapply boundary

sudo nmcli connection add type dummy ifname dummy8 con-name drill ipv4.method manual ipv4.addresses 10.95.0.1/24
sudo nmcli connection up drill
sudo nmcli connection modify drill ipv4.addresses 10.95.0.2/24
ip -4 -br addr show dummy8
sudo nmcli device reapply dummy8
ip -4 -br addr show dummy8
sudo nmcli connection delete drill

Checks:

1. After modify it is still 10.95.0.1;
2. After reapply it is 10.95.0.2;
3. nmcli -g ipv4.addresses agrees with ip addr;
4. The device disappears once the profile is deleted.

FAQ

常见问题

Does reapply drop TCP connections?

Within the properties it supports it usually does not; changing addresses invalidates existing connections, while DNS or route changes generally leave established ones alone.

Why does my change revert after a reboot?

Check whether a higher-priority profile took the device, or whether you edited a file such as /etc/resolv.conf that gets overwritten.

Can nmcli and ifcfg files be mixed?

Since EL9 the keyfile backend is the default; ifcfg files under /etc/sysconfig/network-scripts/ are ignored — do not mix them.

Next steps

• Profile management: /en/nmcli-profiles/
• Troubleshooting: /en/network-troubleshoot/
• Network basics: /en/network-basics/