Changing a server’s IP with nmcli over SSH is the classic way to lock yourself out. The tool has a built-in undo for exactly that, which almost no nmcli cheat sheet mentions. The other traps are quieter: a bond that never comes up, a static profile that keeps its old address after you switch to DHCP, and Ubuntu servers where nmcli isn’t even installed.
This nmcli cheat sheet covers the commands you need to manage NetworkManager from the shell: static and DHCP addresses, routes and DNS, bonds, bridges and VLANs, the profile files on disk, scripting output, troubleshooting, and safe remote changes. Every command and error on this page was run in October 2026 on Rocky Linux 10.2 with NetworkManager 1.56 and Ubuntu 26.04 with NetworkManager 1.54, making the changes on spare network cards so a mistake never cut the management link (one Ubuntu experiment still did, and it is documented below). The whole sheet is also a one-page PDF.
Find the nmcli command you need
Each row is covered further down with the output our lab hosts printed. Changes to profiles need sudo when you work over SSH, so every write command below carries it:
| Task | Command |
|---|---|
| Show devices and their profiles | nmcli device status |
| List saved profiles | nmcli connection show |
| Add a static IP profile | sudo nmcli connection add type ethernet ifname ens20 con-name lab-static ipv4.method manual ipv4.addresses 10.0.1.50/24 ipv4.gateway 10.0.1.1 |
| Activate a profile | sudo nmcli connection up lab-static |
| Add a second address | sudo nmcli connection modify lab-static +ipv4.addresses 10.0.1.51/24 |
| Apply a change without dropping the link | sudo nmcli device reapply ens20 |
| Add a static route | sudo nmcli connection modify lab-static +ipv4.routes "10.20.0.0/16 10.0.1.1" |
| Show one field for a script | nmcli -g IP4.ADDRESS device show ens20 |
| Watch state changes live | nmcli monitor |
| Change something with automatic rollback | sudo nmcli device checkpoint --timeout 60 ens20 -- nmcli device reapply ens20 |
Check NetworkManager on Rocky Linux and Ubuntu
Rocky Linux 10 runs NetworkManager on every install, so nmcli is there from the first boot. Ubuntu Server is different: it configures the network with netplan and systemd-networkd, and on our Ubuntu 26.04 VM the shell reported nmcli: command not found until we installed network-manager, which the Ubuntu section below covers. Start by checking the version and the overall state:
nmcli --version; nmcli generalRocky printed the RHEL build string and a connected state. The METERED column says no (guessed) because nothing told NetworkManager otherwise:
nmcli tool, version 1.56.0-3.el10_2
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN METERED
connected full missing enabled missing enabled no (guessed) Devices and profiles are separate things in NetworkManager, and most confusion comes from mixing them up. A device is the network card. A connection is a saved profile that NetworkManager applies to a device, and one device can have several profiles but only one active at a time. List both:
nmcli device status; nmcli connection showOur Rocky VM had four network cards. The cloud image’s eth0 profile came from cloud-init, and NetworkManager had created a Wired connection N profile with DHCP for each extra card on its own:
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected cloud-init eth0
ens19 ethernet connected Wired connection 1
ens20 ethernet connected Wired connection 2
ens21 ethernet connected Wired connection 3
lo loopback connected (externally) lo
NAME UUID TYPE DEVICE
cloud-init eth0 1dd9a779-d327-56e1-8454-c65e2556c12c ethernet eth0
Wired connection 1 9425fc8b-62ef-3ace-9272-6782d5f52cee ethernet ens19
Wired connection 2 1913fb69-d190-3807-b715-31c12be8ca8f ethernet ens20
Wired connection 3 c8109c5b-5b69-3579-adb3-65a1c52bbc3b ethernet ens21
lo 09e06b7f-d2f6-416e-ad47-cbc0b935eb6d loopback lo You will see those automatic profiles on most fresh installs. They live in /run/NetworkManager/system-connections/, which is memory, so they vanish at reboot and come back the same way. Your own profiles go to /etc/NetworkManager/system-connections/ on Rocky, while Ubuntu with netplan saves them as YAML in /etc/netplan/. Reading needs no privileges, but changing anything over SSH does: without sudo, nmcli connection add failed on both distros with Error: Failed to add 'lab-test' connection: Insufficient privileges and exit code 4, because NetworkManager’s polkit policy only grants that to local console or desktop sessions, not to remote SSH logins.
Hand network cards to NetworkManager on Ubuntu Server
Rocky readers can skip to the next section. On Ubuntu Server, netplan decides which program manages each card, and NetworkManager stays out of the way unless netplan says otherwise, so the rest of this page fails until you hand the cards over. Install it with sudo apt install network-manager. Afterwards nmcli device status showed every card as unmanaged, because Ubuntu’s package ships /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf with unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma. To give one card to NetworkManager, set its renderer in a netplan file:
Hand over a spare card, never the one your SSH session uses: a netplan file like the one below with dhcp4: false on the management card cuts you off the moment you apply it. If the server has only one card, do this from a console you can’t lose. A checkpoint won’t help here, because it cannot undo the netplan file or the networkd state that netplan apply changes.
sudo vim /etc/netplan/60-ens19-nm.yamlThis is the file as we ended up with it. Note dhcp4: false: we first applied it with true and paid for it, as shown below:
network:
version: 2
ethernets:
ens19:
renderer: NetworkManager
dhcp4: falseSet the mode to 600 with sudo chmod 600 /etc/netplan/60-ens19-nm.yaml, since netplan expects its files to be readable by root only, then run sudo netplan apply. NetworkManager now shows a profile called netplan-ens19, generated into /run/NetworkManager/system-connections/. Edit it with nmcli as usual, and netplan saves your change as a new YAML file rather than a keyfile:
sudo nmcli connection modify netplan-ens19 ipv4.method manual ipv4.addresses 10.0.1.40/24 ipv4.dns 10.0.1.53/etc/netplan/ gained 90-NM-cb177419-4682-353f-b54c-7d4f2bd80f64.yaml holding the new address and DNS. We use 10.0.1.40 here because the next section puts 10.0.1.50 on ens20, and the same address on two cards of one host makes NetworkManager refuse the second, as the errors section explains. Three Ubuntu behaviours caught us out, and each one matters before you trust nmcli on a server:
- the original YAML still applies: with
dhcp4: truein it, the nextnetplan applyput the profile on DHCP plus the static address - netplan’s handover lifted the global unmanaged rule, so NetworkManager took every card netplan did not define (on our VM,
ens20andens21, which the examples below use) - a static gateway with
ipv4.route-metricis saved asdhcp4-overrides, so netplan saw two default routes and loggedConflicting default route declarations45 times in our journal
Switching the whole server to NetworkManager with a global renderer: NetworkManager went worse on our cloud VM. eth0 came back with a DHCP address instead of its static one, our SSH session dropped, and a reboot did not fix it, because systemd-networkd also ran a catch-all DHCP file from the dracut initramfs, /run/systemd/network/zzzz-dracut-default.network. On Ubuntu Server, either leave networking to netplan and networkd, or make the switch from a console you can’t lose, such as the hypervisor, IPMI or the cloud provider’s serial console, never over the SSH session it might cut. Our NetworkManager guide for Ubuntu and Debian and the Ubuntu 26.04 netplan static IP guide cover both routes.
Set a static IP address with nmcli
If the card you change is the one your SSH session uses, a typo can cut you off, so practise on a spare card or wrap the change in the checkpoint shown at the end of this page. Create a new profile rather than editing the automatic one, so you can switch back by activating the old profile. The ipv4.route-metric here keeps this test gateway from beating the management card’s default route, which you should do too if the box has more than one gateway:
sudo nmcli connection add type ethernet ifname ens20 con-name lab-static ipv4.method manual ipv4.addresses 10.0.1.50/24 ipv4.gateway 10.0.1.1 ipv4.route-metric 600 ipv4.dns "10.0.1.53 10.0.1.54" ipv4.dns-search example.com ipv6.method disabled
sudo nmcli connection up lab-staticconnection up printed Connection successfully activated. Give it a second before you check, because NetworkManager first probes the network to make sure nobody else uses the address and only then adds it:
nmcli -f GENERAL.STATE,GENERAL.CONNECTION,IP4.ADDRESS,IP4.GATEWAY,IP4.DNS device show ens20The device is connected to the new profile with the address, gateway and both DNS servers. Both distros printed the same block:
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: lab-static
IP4.ADDRESS[1]: 10.0.1.50/24
IP4.GATEWAY: 10.0.1.1
IP4.DNS[1]: 10.0.1.53
IP4.DNS[2]: 10.0.1.54On Rocky the profile became a keyfile in /etc/NetworkManager/system-connections/lab-static.nmconnection, owned by root with mode 600. It is plain INI, and reading it is the fastest way to see what a profile really contains:
[connection]
id=lab-static
uuid=cd67429c-f784-4717-946d-019f61464671
type=ethernet
interface-name=ens20
[ethernet]
[ipv4]
address1=10.0.1.50/24
dns=10.0.1.53;10.0.1.54;
dns-search=example.com;
gateway=10.0.1.1
method=manual
route-metric=600
[ipv6]
addr-gen-mode=default
method=disabled
[proxy]Ubuntu with netplan stores the same profile somewhere else, which the Ubuntu section above explains. Our static IP guide for Rocky Linux and AlmaLinux walks through the same setup with nmtui and the reasoning behind each field.
Change addresses, routes and DNS on a live connection
nmcli connection modify only changes the saved profile. Nothing happens on the wire until you apply it, and there are two ways to do that. nmcli device reapply ens20 updates the running device in place without taking the link down, which suits addresses, routes and DNS. nmcli connection up lab-static tears the connection down and brings it back, which is needed for some properties and always works. Prefix a property with + to add a value and - to remove one, instead of retyping the whole list:
sudo nmcli connection modify lab-static +ipv4.addresses 10.0.1.51/24
sudo nmcli device reapply ens20After the address probe finished, ip -br addr show ens20 listed both addresses, and -ipv4.addresses 10.0.1.51/24 followed by another reapply removed the second one again:
ens20 UP 10.0.1.50/24 10.0.1.51/24 Static routes work the same way. Each route is the destination and the next hop in one quoted string, with an optional metric as a third field:
sudo nmcli connection modify lab-static +ipv4.routes "10.20.0.0/16 10.0.1.1"
sudo nmcli device reapply ens20ip route | grep 10.20 confirmed the route, and it inherited the profile’s metric of 600:
10.20.0.0/16 via 10.0.1.1 dev ens20 proto static metric 600 DNS is where multi-homed servers surprise people, because every active profile can add servers. ipv4.ignore-auto-dns yes drops the servers DHCP hands out on that profile, and ipv4.dns-priority decides whose servers come first, lower numbers winning. On Rocky, which writes /etc/resolv.conf directly, the router’s server (shown here as 10.0.0.1) came first after activation, and grep nameserver /etc/resolv.conf printed this:
nameserver 10.0.0.1
nameserver 10.0.1.53
nameserver 10.0.1.54After sudo nmcli connection modify lab-static ipv4.dns-priority 50 ipv4.ignore-auto-dns yes, a reapply and a two-second wait, our two servers moved ahead of the router’s:
nameserver 10.0.1.53
nameserver 10.0.1.54
nameserver 10.0.0.1Ubuntu hands DNS to systemd-resolved instead, so check it there with resolvectl dns ens20 rather than reading /etc/resolv.conf, which is only a stub on Ubuntu. On our Ubuntu VM that command still showed only the router, because networkd’s catch-all DHCP file from the Ubuntu section was also running on the card, which is one more reason to hand cards over cleanly.
Switch a profile between static and DHCP
Switching to DHCP by setting only the method is the mistake most guides make. NetworkManager keeps the static addresses and gateway as extra settings on a DHCP profile, so the box ends up with both:
sudo nmcli connection modify lab-static ipv4.method auto
nmcli -g ipv4.method,ipv4.addresses,ipv4.gateway connection show lab-staticThe profile still carries the static address and gateway next to the new method:
auto
10.0.1.50/24
10.0.1.1Clear them in the same command with empty strings, and the profile becomes pure DHCP. Going back to static is the reverse, with the address and gateway set again before connection up:
sudo nmcli connection modify lab-static ipv4.method auto ipv4.addresses "" ipv4.gateway ""This time nmcli -g ipv4.method,ipv4.addresses,ipv4.gateway connection show lab-static printed only auto, so nothing static was left behind.
Get nmcli output you can script
The default table output changes width with its content, so never parse it with awk. nmcli has three flags for scripts, and they combine:
-t: terse, colon-separated fields with no padding-f: only the fields you name-g: values only, one field per line (short for-m tabular -t -f)
These are the forms you will use most in scripts. The -g output has no headers or padding, so you can assign it straight to a variable:
nmcli -t -f NAME,TYPE,DEVICE connection show --active
nmcli -g IP4.ADDRESS device show ens20
nmcli -g ipv4.addresses,ipv4.dns connection show lab-staticNote that connection show takes profile property names in lower case (ipv4.addresses), while device show takes runtime fields in upper case (IP4.ADDRESS). Property groups use their full setting names in -f: ethernet.cloned-mac-address failed with Error: invalid field 'ethernet.cloned-mac-address', and 802-3-ethernet.cloned-mac-address worked. Two details of terse output catch scripts out. Colons inside values are escaped, so nmcli -g GENERAL.HWADDR device show ens20 printed BC\:24\:11\:0D\:1F\:78 until we added -e no, and a field with several values joins them with | , which turned two addresses into 10.0.1.51/24 | 10.0.1.50/24. Exit codes tell a script what went wrong without parsing text:
| Exit code | Meaning | What triggered it in our lab |
|---|---|---|
| 0 | Success | Any command that worked |
| 2 | Invalid input | An invalid IP address or field name |
| 4 | Activation or add failed | No suitable device, insufficient privileges, address in use |
| 8 | NetworkManager not running | nmcli device status with the service stopped |
| 10 | Connection, device or AP does not exist | nmcli connection up nope, nmcli device show ens99 |
Create bonds, bridges and VLANs
A bond, bridge or VLAN is a profile for a virtual device, and the physical cards join it through port profiles. Create the bond itself with its mode and the address it carries:
sudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100" ipv4.method manual ipv4.addresses 10.0.2.10/24 ipv6.method disabled
sudo nmcli connection add type ethernet con-name bond0-port1 ifname ens20 port-type bond controller bond0
sudo nmcli connection add type ethernet con-name bond0-port2 ifname ens21 port-type bond controller bond0Now activate it. This is where the trap is: sudo nmcli connection up bond0 answered Connection successfully activated (controller waiting for ports), /proc/net/bonding/bond0 showed MII Status: down and no active port, and the bond stayed that way. Both cards were still busy with their automatic Wired connection profiles, so NetworkManager never switched them over. Bring the ports up yourself:
sudo nmcli connection up bond0-port1
sudo nmcli connection up bond0-port2Once both ports joined, the bond came up with the address, and you can confirm the state in the kernel’s own view:
Bonding Mode: fault-tolerance (active-backup)
Currently Active Slave: ens20
MII Status: up
Slave Interface: ens20
MII Status: up
Slave Interface: ens21
MII Status: upTo have the ports join on their own whenever the bond starts, create the bond with connection.autoconnect-ports true (note true, since yes is rejected for this property). With that set, a plain connection up bond0 pulled in both ports on our Rocky host within four seconds. Taking a port down shows failover working: after sudo nmcli connection down bond0-port1, /proc/net/bonding/bond0 reported Currently Active Slave: ens21. Bridges and VLANs use the same pattern. Delete the bond first with sudo nmcli connection delete bond0 bond0-port1 bond0-port2, because its port profiles still claim ens20. Both of these worked on our Rocky host, and the bridge again needed its port brought up explicitly:
sudo nmcli connection add type bridge con-name br0 ifname br0 bridge.stp no ipv4.method manual ipv4.addresses 10.0.3.10/24 ipv6.method disabled
sudo nmcli connection add type ethernet con-name br0-port1 ifname ens20 port-type bridge controller br0
sudo nmcli connection up br0-port1
sudo nmcli connection add type vlan con-name vlan30 dev ens21 id 30 ipv4.method manual ipv4.addresses 10.0.30.10/24 ipv6.method disabled
sudo nmcli connection up vlan30bridge link show listed ens20 with master br0 state forwarding, and the VLAN appeared as ens21.30@ens21 with vlan protocol 802.1Q id 30. Team devices are gone on Rocky Linux 10: nmcli connection add type team failed with team support is disabled in this build. Ubuntu still accepted the profile but failed to activate it with No reason given, so use a bond on both. Our network bonding guide for Rocky Linux covers the other bond modes.
Work with the profile files on disk
Editing keyfiles by hand is fine, as long as you respect the permissions and tell NetworkManager to reread them. Find the file behind a profile with nmcli -f NAME,FILENAME connection show. On Rocky, a keyfile that other users can read is silently ignored, which we proved with a throwaway profile (on Ubuntu with netplan the same profile is a YAML file in /etc/netplan/ instead):
sudo nmcli connection add type ethernet ifname ens20 con-name perm-test ipv4.method disabled ipv6.method disabled autoconnect no
sudo chmod 644 /etc/NetworkManager/system-connections/perm-test.nmconnection
sudo nmcli connection reloadThe profile disappeared from nmcli connection show with no error on the terminal. The reason is only in the journal:
<warn> [1792752022.0096] keyfile: load: "/etc/NetworkManager/system-connections/perm-test.nmconnection": failed to load connection: File permissions (100644) are insecureSet the mode back to 600 and load just that file with sudo nmcli connection load /etc/NetworkManager/system-connections/perm-test.nmconnection, which brought the profile straight back. nmcli connection reload rereads every file, connection load only the one you name. A few more file commands are worth knowing:
| Job | Command |
|---|---|
| Print a keyfile without touching the system | nmcli --offline connection add type ethernet con-name offline-test ifname ens21 ipv4.method manual ipv4.addresses 10.0.1.80/24 |
| Find the file behind each profile | nmcli -f NAME,FILENAME connection show |
| Reread all files after manual edits | sudo nmcli connection reload |
| Import a WireGuard config | sudo nmcli connection import type wireguard file /tmp/wg0.conf |
| Move one old profile to a keyfile | sudo nmcli connection migrate lab-static |
The --offline form is handy for building keyfiles in Ansible or cloud-init, because it prints the file and needs no running daemon. Be careful with connection migrate: with no argument it migrates every profile, so Rocky 10, which has no ifcfg files left, migrated the automatic in-memory Wired connection profiles and cloud-init’s eth0 profile on our host. Name the profile you mean. The WireGuard import created a wg0 profile with the listen port and address from the file; our WireGuard VPN guide covers the peers and keys.
Watch and debug NetworkManager
When a profile won’t come up, watch what NetworkManager is doing instead of guessing. nmcli monitor prints every state change as it happens. We ran it while bouncing lab-cp, a static profile on ens21 created with sudo nmcli connection add type ethernet ifname ens21 con-name lab-cp ipv4.method manual ipv4.addresses 10.0.4.10/24 ipv6.method disabled and activated with sudo nmcli connection up lab-cp. While the monitor ran in one terminal, a second ran sudo nmcli connection down lab-cp and then up again:
NetworkManager is running
ens21: deactivating
ens21: disconnected
ens21: using connection 'Wired connection 3'
ens21: connecting (prepare)
ens21: connecting (configuring)
ens21: connecting (getting IP configuration)
ens21: deactivating
ens21: disconnected
ens21: using connection 'lab-cp'
ens21: connecting (prepare)
ens21: connecting (configuring)
ens21: connecting (getting IP configuration)
ens21: connecting (checking IP connectivity)
ens21: connecting (starting secondary connections)
ens21: connectedThe fourth line is a lesson in itself: the moment our profile went down, NetworkManager activated the automatic Wired connection 3 on the same card, because that profile still had autoconnect on. Delete automatic profiles you don’t want, or they keep coming back. For a deeper look, raise the log level for a moment and read the journal:
sudo nmcli general logging level DEBUG domains ALL
sudo journalctl -u NetworkManager -f
sudo nmcli general logging level INFO domains DEFAULTFailed activations also print a ready-made filter, such as Hint: use 'journalctl -xe NM_CONNECTION=<uuid> + NM_DEVICE=ens20' to get more details, so copy that line rather than searching the whole journal. nmcli networking connectivity printed full on our Rocky host, and nmcli radio showed the Wi-Fi switch there even with no Wi-Fi hardware.
Fix common nmcli errors
These are the errors we triggered in the lab, with the exact text NetworkManager printed.
Error: “Insufficient privileges”
You ran a change without sudo over SSH. Read-only commands work for any user, but polkit only lets a local console or desktop session change the system’s network, so prefix every add, modify, up and delete with sudo. nmcli general permissions shows auth against each action you can’t do directly.
Error: “No suitable device found for this connection”
The profile’s ifname doesn’t match any card. Our profile for a non-existent ens99 failed with No suitable device found for this connection (device eth0 not available because profile is not compatible with device (mismatching interface name)). Check the real names with nmcli device status and fix the profile with sudo nmcli connection modify ghost connection.interface-name ens20.
Error: “IP configuration could not be reserved (no available address, timeout, etc.)”
The vague message hides a precise cause, and on our hosts it was an address conflict. The journal said IP address 10.0.1.50 cannot be configured because it is already in use in the network by host BC:24:11:AE:24:F9. Another machine, or another card on the same host, answered ARP for the address. On our Ubuntu VM, 10.0.1.50 was still assigned to ens19 from an earlier test, and the VM’s own cards answered for it. Linux answers ARP for any of its addresses on any card by default, so a leftover address on a different interface counts too. Find the owner from the MAC, or pick another address.
Error: “gateway cannot be set if there are no addresses configured”
You set ipv4.gateway on a manual profile without ipv4.addresses. Add both in the same command, as in the static IP example above.
Error: “failed to modify ipv4.addresses: invalid IP address”
A typo in the address, such as 10.0.1.300/24, which gave invalid IP address: Invalid IPv4 address '10.0.1.300' and exit code 2. The profile is not created at all, so fix the value and run the command again.
Warning: “There is another connection with the name”
Profile names don’t have to be unique, and NetworkManager only warns. Once two profiles share a name, delete removes every one of them, which is how our sudo nmcli connection delete dup removed two profiles at once, while modify changes only one: we set autoconnect off by name and only one of the two dup profiles changed. Refer to duplicates by the UUID the warning prints, or rename one with connection.id.
Error: “NetworkManager is not running”
The service is stopped or crashed, and nmcli exits with 8. Start it with sudo systemctl start NetworkManager and check journalctl -u NetworkManager if it doesn’t stay up. On Ubuntu Server, also check whether netplan uses networkd instead, in which case NetworkManager isn’t meant to be running.
Error: “set managed failed: No such method SetManaged”
The nmcli binary is newer than the NetworkManager daemon that is running. Our Rocky clone had run dnf upgrade at first boot, which updated the package at 10:12 while the old daemon kept running, and nmcli device set ens21 managed no failed until NetworkManager restarted at 10:28. Restart the service (or reboot) after every NetworkManager update. nmcli’s own version-mismatch warning stayed silent here, because both the new and the old build reported 1.56.0.
Change a remote server’s IP without locking yourself out
nmcli device checkpoint snapshots the network state, runs your command, and rolls everything back unless you confirm within the timeout. It exists since NetworkManager 1.40 but appears in almost no guide, and it is the safest way to change the card you are connected through. We tested it on the lab-cp profile from the monitoring section, which held 10.0.4.10/24 on ens21, by changing the address inside a 15-second checkpoint:
sudo nmcli device checkpoint --timeout 15 ens21 -- sh -c 'nmcli connection modify lab-cp ipv4.addresses 10.0.4.20/24 && nmcli device reapply ens21'nmcli applied the change and asked for confirmation. Typing Yes commits it, and the command exits with 0:
Connection successfully reapplied to device 'ens21'.
Type "Yes" to commit the changes: YesIf you don’t answer, or your SSH session dies because the new address is wrong, nothing is committed. Two details from our tests matter here:
- the rollback waits for the full timeout, even if nmcli exits early
- it restores the saved profile as well as the live address
Run without a terminal, the same command printed the prompt, read nothing and exited with 1, yet the card kept 10.0.4.20 for the rest of the 15 seconds. After the timeout both ip -br addr show ens21 and nmcli -g ipv4.addresses connection show lab-cp were back to 10.0.4.10/24. For a real change on eth0, give yourself a timeout of 60 to 120 seconds, run it inside tmux so a dropped session can’t kill nmcli, and reconnect to the new address in a second terminal before you type Yes.
If you are working toward the RHCSA, nmcli is the tool its networking objectives are built around, and Sander van Vugt’s Red Hat RHCSA 10 Cert Guide (paid link) (EX200, Pearson, June 2026) is the current guide written for RHEL 10. Our systemctl cheat sheet covers the service side when NetworkManager itself misbehaves.
