LFCS 99 🐧 NetworkManager — Concepts - KandZ

⏱️ Estimated read: 9 min | |

NetworkManager is a daemon that manages network interfaces and connections on modern Linux systems. It is not a configuration file format or a wrapper around ip—it is a privileged service that runs in the background, detecting hardware, activating profiles, and applying configuration through the kernel. The LFCS exam tests the conceptual model: the separation between devices and connections, the state machine that governs activation, and the persistent storage that survives reboots.

Key point: A device is the physical or virtual interface. A connection is a named profile containing the configuration. NetworkManager binds a connection to a device to activate it. One device can have many connections, but only one active at a time .

Why NetworkManager exists

The dynamic networking problem. Legacy tools like ifupdown and static configuration files assume a network that does not change. A laptop moves between Wi-Fi networks. A server gains a new interface. A VPN connects and disconnects. NetworkManager was designed to handle this dynamic environment: it continuously monitors hardware, selects the best available connection, and activates it automatically .

The abstraction problem. Raw ip commands modify kernel state directly. They have no memory of intent, no concept of a “profile,” and no mechanism for automatic reconnection. NetworkManager introduces the connection profile: a persistent record of how a network should be configured. The daemon reads these profiles and applies them to devices, reconciling the desired state with the current hardware state .

The multi-backend problem. Different distributions historically used different network configuration systems: ifcfg files on RHEL, /etc/network/interfaces on Debian, Netplan on Ubuntu. NetworkManager provides a unified abstraction. On RHEL and Fedora, it is the primary network manager. On Ubuntu, Netplan renders configuration to NetworkManager or systemd-networkd . The LFCS exam expects familiarity with NetworkManager’s model regardless of the underlying backend.

The D-Bus problem. NetworkManager exposes its API over D-Bus on the system bus. The nmcli command, nmtui (text user interface), and graphical applets are all clients of this API. They do not edit configuration files directly—they send D-Bus messages to the daemon, which validates and applies the changes . This is why nmcli connection modify does not take effect until the connection is reactivated: the daemon must re-read the profile and reapply it.

The trade-off. NetworkManager adds a layer of abstraction and a daemon that must be running. For simple, static servers, it can feel like overhead. But for any system that needs dynamic network handling—which includes most modern Linux installations—it is the standard.

a. Devices versus connections

The most important conceptual distinction in NetworkManager is between a device and a connection. A device is the interface itself: eth0, wlan0, enp0s3. It exists because the kernel detected hardware. A connection is a profile: a named collection of settings that describes how to configure a device. The profile is stored on disk; the device is a runtime object .

# List devices and their current state
nmcli device status

# List all connection profiles (active and inactive)
nmcli connection show

# List only active connections
nmcli connection show --active

The device status output shows each interface, its type, its state, and the connection currently bound to it. A device in the disconnected state has no active connection. A device in the connected state has one. The connection show output lists profiles by name, UUID, type, and the device they are attached to (if active) .

A single device can have multiple connection profiles. For example, a laptop’s Wi-Fi interface might have one profile for the office network and another for home. NetworkManager selects the appropriate profile based on availability and priority. The profiles are not active simultaneously; one is bound to the device, and the others wait .

b. The device state machine

NetworkManager tracks each device through a series of states. The state determines what operations are valid and what the device is currently doing. The nmcli device status command shows a simplified state, but the full state machine is exposed through the D-Bus API and the nmcli output .

State	Meaning
`unmanaged`	Device is recognized but not controlled by NetworkManager
`unavailable`	Device is managed but cannot be used (no carrier, firmware missing)
`disconnected`	Device is idle, ready to be activated
`prepare`	Device is preparing (changing MAC, setting link properties)
`config`	Device is associating with the network (Wi-Fi, modem)
`need-auth`	Device requires credentials (Wi-Fi password, VPN secret)
`ip-config`	Device is requesting IP addresses and routes
`activated`	Device has an active connection
`deactivating`	Connection is being torn down
`failed`	Connection attempt failed

The activated state is the goal. A device in disconnected is healthy but has no connection. A device in failed requires intervention: the connection attempt failed, and NetworkManager will not retry until the profile is modified or the device is manually reconnected .

c. Persistent storage and the keyfile format

Connection profiles are stored as keyfiles under /etc/NetworkManager/system-connections/. Each profile is an INI-style file with a .nmconnection extension. The file contains sections for connection (name, UUID, type), ipv4, ipv6, and any other settings relevant to the connection type .

# /etc/NetworkManager/system-connections/static-eth0.nmconnection
[connection]
id=static-eth0
uuid=...
type=ethernet
interface-name=enp0s3

[ipv4]
method=manual
address1=192.168.1.10/24,192.168.1.1
dns=1.1.1.1;

The permissions on these files are critical. They can contain secrets (Wi-Fi passwords, VPN credentials). NetworkManager enforces 0600 ownership by root and will refuse to load a profile that is group- or world-readable . Hand-editing a keyfile requires setting the correct permissions and running nmcli connection reload to make NetworkManager read the change, because the daemon does not monitor the directory for modifications .

The nmcli command is the preferred interface for modifying profiles. It validates settings, applies the correct permissions, and triggers a reload. Editing the keyfile directly is acceptable for automation or recovery, but the manual steps must be followed.

Complete Example Session

# ============================================
# PART 1: LIST DEVICES
# ============================================

nmcli device status
# DEVICE  TYPE      STATE         CONNECTION
# enp0s3  ethernet  connected     Wired connection 1
# enp0s8  ethernet  disconnected  --
# lo      loopback  unmanaged     --

# ============================================
# PART 2: LIST CONNECTIONS
# ============================================

nmcli connection show
# NAME                 UUID                                  TYPE      DEVICE
# Wired connection 1   a1b2c3d4-...                          ethernet  enp0s3

# ============================================
# PART 3: INSPECT A CONNECTION
# ============================================

nmcli connection show "Wired connection 1"
# Displays all settings: ipv4.method, ipv4.addresses, etc.

# ============================================
# PART 4: CREATE A NEW PROFILE
# ============================================

sudo nmcli connection add type ethernet con-name static-eth0 ifname enp0s8 \
    ipv4.method manual \
    ipv4.addresses 192.168.1.50/24 \
    ipv4.gateway 192.168.1.1 \
    ipv4.dns 1.1.1.1
# The profile is created but not activated.

# ============================================
# PART 5: ACTIVATE THE PROFILE
# ============================================

sudo nmcli connection up static-eth0
# NetworkManager binds the profile to enp0s8 and applies the configuration.

# ============================================
# PART 6: VERIFY DEVICE STATE
# ============================================

nmcli device status
# enp0s8  ethernet  connected  static-eth0

# ============================================
# PART 7: LOCATE THE KEYFILE
# ============================================

ls -l /etc/NetworkManager/system-connections/
# -rw------- root root static-eth0.nmconnection

# ============================================
# PART 8: MODIFY A SETTING
# ============================================

sudo nmcli connection modify static-eth0 ipv4.dns 8.8.8.8
# The saved profile is updated, but the running device is not.

# ============================================
# PART 9: REAPPLY WITHOUT DISCONNECT
# ============================================

sudo nmcli device reapply enp0s8
# Applies the saved profile to the running device without a full reconnect.

The nine parts trace the NetworkManager workflow: listing devices, listing profiles, inspecting settings, creating a profile, activating it, verifying state, locating the keyfile, modifying settings, and reapplying changes without dropping the link.

Quick Reference

Device Commands

Command	Purpose
`nmcli device status`	List devices and their states
`nmcli device show <dev>`	Full runtime details for a device
`nmcli device disconnect <dev>`	Disconnect and prevent auto-reconnect
`nmcli device reapply <dev>`	Apply saved profile without reconnect

Connection Commands

Command	Purpose
`nmcli connection show`	List all profiles
`nmcli connection show --active`	List active profiles
`nmcli connection add`	Create a new profile
`nmcli connection modify`	Edit a saved profile
`nmcli connection up`	Activate a profile
`nmcli connection down`	Deactivate a profile

Keyfile Location

Path	Purpose
`/etc/NetworkManager/system-connections/`	Persistent profile storage
`*.nmconnection`	INI-style profile file
Permissions	`0600`, owned by `root`

Best Practices

✅ Do This:

nmcli device status
<!-- Check device state before creating a profile --> # ✅

nmcli connection modify ... && nmcli device reapply ...
<!-- Use reapply to avoid dropping the link -->       # ✅

nmcli connection reload
<!-- After editing a keyfile manually -->            # ✅

❌ Don’t Do This:

# Edit keyfile without chmod 600
<!-- NetworkManager refuses to load it -->           # ❌

# Assume `connection modify` changes the running device
<!-- Saved profile changes require reapply or up -->  # ❌

# Use `connection down` expecting no auto-reconnect
<!-- autoconnect may reactivate it; use device disconnect --> # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Profile not loading	Wrong permissions on keyfile	`chmod 600`, owned by `root`
`connection modify` has no effect	Profile updated but not reapplied	`nmcli device reapply` or `connection up`
Device stays `unmanaged`	Explicitly set or `NetworkManager.conf`	`nmcli device set managed yes`
Cannot delete profile	Profile is active	`connection down` first
`connection down` reactivates	`autoconnect` is enabled	`device disconnect` instead

Real-World Examples

1. List Device States

nmcli device status

2. List All Profiles

nmcli connection show

3. Create Static Ethernet Profile

nmcli con add type ethernet con-name static-eth0 ifname enp0s3 \
    ipv4.method manual ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1

4. Activate Profile

nmcli con up static-eth0

5. Deactivate Profile

nmcli con down static-eth0

6. Disconnect Device (No Auto-Reconnect)

nmcli device disconnect enp0s3

7. Reapply Changes

nmcli device reapply enp0s3

8. Reload Keyfiles

nmcli con reload

9. Set Device Managed

nmcli device set enp0s3 managed yes

10. Delete Profile

nmcli con delete static-eth0

Visual

Device vs Connection

┌──────────────────────────────────────────────┐
│  DEVICE (physical interface)                 │
│  enp0s3, enp0s8, wlan0                       │
│  Runtime object, detected by kernel          │
└──────────────────┬───────────────────────────┘
                   │
                   │ NetworkManager binds
                   ▼
┌──────────────────────────────────────────────┐
│  CONNECTION (profile)                        │
│  "Wired connection 1", "static-eth0"         │
│  Persistent keyfile in /etc/NetworkManager/  │
└──────────────────────────────────────────────┘

A device without a connection is idle. A connection without a device is inactive.

State Flow

unmanaged → unavailable → disconnected
                           │
                           ▼ (connection up)
                       prepare → config → ip-config
                           │
                           ▼
                       activated
                           │
                           ▼ (connection down)
                       deactivating → disconnected

The activated state is the goal. failed requires intervention.

Summary

Item	Value
Daemon	`NetworkManager.service`
Device	Physical/virtual interface
Connection	Named profile with configuration
Profile storage	`/etc/NetworkManager/system-connections/*.nmconnection`
Keyfile permissions	`0600`, owned by `root`
CLI tool	`nmcli`
TUI tool	`nmtui`
D-Bus API	`org.freedesktop.NetworkManager`
Device state	`unmanaged`, `disconnected`, `activated`, `failed`

Key takeaways:

NetworkManager separates devices from connections. The device is the interface; the connection is the profile. A profile must be activated on a device to take effect .
Profiles are stored as keyfiles. They live under /etc/NetworkManager/system-connections/ and require 0600 permissions because they can contain secrets .
connection modify does not change the running device. The saved profile is updated, but the device must be reactivated or reapplied to see the change .
The state machine determines validity. A device in disconnected is ready. A device in failed requires intervention. unmanaged means NetworkManager is not controlling it .
device disconnect is not the same as connection down. connection down may allow auto-reconnect; device disconnect prevents it until manual intervention .

Remember: NetworkManager is a daemon, not a file format. It manages devices and connections through D-Bus, stores profiles as keyfiles, and tracks each device through a state machine. The nmcli command is the interface, but the model is what matters: devices are hardware, connections are intent, and activation is the act of binding one to the other.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!