Learn › RHCSA (EX200) › Basic Networking
nmcli - a hands-on Linux lab on a real virtual machine.
Make a network setting survive a reboot. The difference between a live runtime change (gone at the next boot) and a saved connection profile with connection.autoconnect yes (read back at every boot). Read the boot flag with nmcli -f connection.autoconnect con show, find the RHEL 10 keyfile at /etc/NetworkManager/system-connections/NAME.nmconnection (mode 600), control it now with nmcli con up and con down, and re-read a hand-edited keyfile with nmcli con reload. Serves EX200 basic-networking: configure network settings that start automatically at boot.
It is late. A server dropped off the network and you are the one paged. You SSH in through the console, set a static IP by hand, and the machine answers again. You close the ticket and go back to sleep. At 3 a.m. the box reboots for a routine patch, and it comes up with the wrong address. The pager fires a second time. You set the same IP again, staring at the screen, wondering why it never stuck.
It never stuck because the address you set was only running in memory. Nothing on disk told the machine to use it again. This lesson is about the difference between a setting that is live right now and a setting that survives a reboot, and the one flag that turns the first into the second. On RHEL 10 that job belongs to NetworkManager and its command-line front end, nmcli.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2). The connection here is named demo and lives on a throwaway dummy0 interface, so the real network was never touched. A few values vary per machine: your connection names, your interface names (ens3, enp1s0, and so on), and the exact files listed. What is stable everywhere is the SHAPE: a saved connection is a keyfile on disk, connection.autoconnect yes brings it up at boot, and nmcli con up/down control it right now.
NetworkManager is the service that owns networking on a modern RHEL system. It decides which interface gets which address, which connection is active, and what happens at boot. You do not talk to it by editing a pile of scripts. You talk to it through a saved object called a connection profile.
Think of a connection profile as a saved recipe for an interface: the address, the gateway, the DNS servers, and whether to bring it up automatically. nmcli, short for NetworkManager command line interface, is the tool you use to create, read, change, and activate those profiles. The word con in the commands below is just the short form of connection.
Here is the trap that paged you twice. There are two layers to a network setting. One is the running state, held in memory by the kernel and NetworkManager: it is what the machine is doing this very second. The other is the saved profile on disk: it is what the machine will do next time it starts.
A raw ip addr add command, or any change that is not written into a connection profile, only touches the running state. It works until the next reboot, then vanishes without a trace. A change stored in a connection profile with autoconnect turned on is read back at every boot. The whole point of a persistent connection is that layer two agrees with layer one, so the machine comes back exactly as you left it.
Every connection profile carries a property named connection.autoconnect. When it is yes, NetworkManager brings that profile up on its own at boot and whenever its device appears. When it is no, the profile just sits there saved but idle until you activate it by hand. This single property is the line between a setting that survives a reboot and one that does not.
You read one property of a saved profile with nmcli -f <property> con show <name>. The -f flag means field: it filters the output down to just the property you asked for. Read the autoconnect setting of the demo connection:
nmcli -f connection.autoconnect con show demo
prompt: [root@servera ~]# answer: nmcli -f connection.autoconnect con show demo output: connection.autoconnect: yes hint: The reader is nmcli -f, the property is connection.autoconnect, then con show and the name: nmcli -f connection.autoconnect con show demo
The single line connection.autoconnect: yes is the answer to one question: will this profile come back on its own after a reboot? A yes means NetworkManager activates demo automatically at every boot, so its address survives. A no would mean the profile is saved but dormant until someone runs it. When you build a connection for the exam, you set this to yes, either as connection.autoconnect yes in the con add line or later with nmcli con mod demo connection.autoconnect yes. This is the property that fixes the 3 a.m. page.
A connection profile is not magic; it is a file. On RHEL 10, NetworkManager stores each profile as a keyfile in one directory: /etc/NetworkManager/system-connections/. Every saved connection is one file there, named after the connection with a .nmconnection extension. List that directory and you see every profile the machine will read at boot.
List the keyfile store:
ls /etc/NetworkManager/system-connections/
prompt: [root@servera ~]# answer: ls /etc/NetworkManager/system-connections/ output: demo.nmconnection enp1s0.nmconnection hint: Plain ls on the keyfile directory: ls /etc/NetworkManager/system-connections/
Each line is one saved connection profile. demo.nmconnection is the demo connection you just read; enp1s0.nmconnection is a profile for another interface. The file name is the connection name plus .nmconnection. Inside, it is a plain-text INI file with sections like [connection] and [ipv4], holding the address, gateway, DNS, and the autoconnect line. Because these files persist on disk, the connections they describe persist across reboots. This is the RHEL 10 keyfile store, and it replaced the old ifcfg-* script style.
These keyfiles hold secrets like Wi-Fi passwords, so NetworkManager keeps them locked down to mode 600, readable and writable by root only. Do not loosen those permissions. If you copy a keyfile in from elsewhere and it is group- or world-readable, NetworkManager will refuse to load it and the connection silently will not appear. When in doubt, run chmod 600 on the file and reload.
Autoconnect handles the next boot. To act on the connection right this second, you activate and deactivate it by hand. nmcli con up <name> brings a saved profile up now, applying its address to the device. nmcli con down <name> takes it down now, without deleting the saved profile. The profile stays on disk either way; up and down only change the running state.
This is the pair you reach for after you modify a connection. You change a property with nmcli con mod, which writes the keyfile. Then you run nmcli con up demo to make the running state catch up to what you just saved, or nmcli con down demo to drop it now without deleting the file. To see what is active this second, ask NetworkManager for its device status with nmcli dev status. That command lists every device, its state, and the connection currently bound to it. Check the running state now:
nmcli dev status
prompt: [root@servera ~]# answer: nmcli dev status output: DEVICE TYPE STATE CONNECTION ens3 ethernet connected Wired connection 1 dummy0 dummy connected demo lo loopback connected lo hint: The running-state reader is nmcli dev status, with nothing after it: nmcli dev status
Each row is one device and the connection bound to it right now. The dummy0 row shows connected in the STATE column with demo in the CONNECTION column. That means the demo profile is active on that device this second. Run nmcli con up demo and NetworkManager reads the saved keyfile and makes it live, so demo shows here as connected. Run nmcli con down demo and that row drops to a disconnected state while the file stays on disk untouched. Remember the pattern: con mod to save a change, con up to apply it now, nmcli dev status to confirm what is bound. The autoconnect flag then repeats that up for you at every boot.
Your device and connection names will differ. The ground-truth machine names its primary interface ens3 on the connection Wired connection 1. Yours might be enp1s0, eth0, or something else, and the demo connection here rides a throwaway dummy0. Read the STATE and CONNECTION columns, not the exact names. A device is live when STATE says connected and a connection name sits beside it. A device with an empty CONNECTION column has no active profile bound.
Sometimes you edit a keyfile directly with a text editor instead of going through nmcli con mod. NetworkManager does not notice file changes on its own, so your edit sits on disk while the running NetworkManager keeps using the old version it loaded earlier. The fix is nmcli con reload: it tells NetworkManager to re-read every keyfile in the store and pick up what changed.
Reload the profiles from disk:
nmcli con reload
prompt: [root@servera ~]# answer: nmcli con reload output: hint: The re-read command is nmcli con reload, with nothing after it: nmcli con reload
No output means success: con reload is silent when it works. NetworkManager has now re-read the keyfiles under /etc/NetworkManager/system-connections/, so any change you made in an editor is loaded into its memory. One thing to remember: reload updates the saved profile in NetworkManager, but it does not automatically re-apply an active connection. After a reload that changed a live connection, run nmcli con up <name> to push the new settings onto the running device. The rule of thumb: edited a file by hand, run con reload, then con up to apply.
Scaffolding off. No command is printed this time. You have every piece you need.
You have built a connection named demo and a colleague asks the one question that matters before they trust the box: will this address come back on its own after the next reboot? You do not want to activate it, and you do not want to list files. You want to read back the single property that decides boot-time behavior for that saved profile. Which command reads just the connection.autoconnect field of the demo connection?
prompt: [root@servera ~]# answer: nmcli -f connection.autoconnect con show demo output: connection.autoconnect: yes hint: It is the field reader, not con up. The shape is nmcli -f connection.autoconnect con show demo.
nmcli -f connection.autoconnect con show demo prints one line, connection.autoconnect: yes, and that yes is the whole answer: the connection will come up on its own at the next boot. This is the check that closes the 3 a.m. ticket for good. nmcli con up would have made it live right now, and ls would have proven the file exists, but only reading connection.autoconnect answers the reboot question directly.
You earned this cheat sheet. Every row is a form you just ran or built:
The one thing to burn in for the exam: a change is only persistent if it lives in a connection profile with connection.autoconnect yes. A raw runtime change is gone at the next reboot. Save it in the profile, set autoconnect, and confirm with nmcli -f connection.autoconnect con show.
After you build or modify a connection, prove it two ways before you trust it. First, nmcli -f connection.autoconnect con show <name> to confirm it will come back at boot. Second, nmcli con up <name> to confirm it activates cleanly right now. On the real exam, a task that says the address must survive a reboot is asking for exactly that autoconnect flag, saved in the keyfile.
The practice terminal has walked you through the whole loop. You read the boot-time flag with nmcli -f connection.autoconnect con show. You found the keyfile on disk with ls /etc/NetworkManager/system-connections/. You controlled the connection right now with nmcli con up and con down, and re-read a hand-edited keyfile with nmcli con reload. Every one of those you typed yourself.
Operation Uplink is where you run these against a real RHEL 10 machine. A full VM boots for you, with its own real interfaces waiting to be configured. The mission hands you objectives that use exactly what you practiced here. Build a connection profile, set it to autoconnect, activate it now, and confirm it will survive a reboot. One difference from this lesson: the mission shows no commands. You read the objective, recall the nmcli con and connection.autoconnect forms, and type them. That recall is what makes it stick on exam day.
Finish the other basic-networking lessons, then go make a connection that comes back on its own.
Practice Persistent Network Connections in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.