Understanding NetworkManager on Fedora
You rebooted your Fedora workstation and the network icon is grayed out. Or you edited a config file to set a static IP and now the system has no route to the internet. Or you are trying to automate a connection and nmcli output looks like a wall of text with no clear path forward. NetworkManager is the engine driving all network state on Fedora. It controls wired Ethernet, Wi-Fi, VPNs, mobile broadband, and bridges. It also talks to systemd-resolved for DNS. When the network breaks, NetworkManager is almost always the place to look.
What's actually happening
NetworkManager separates hardware from configuration. The daemon tracks two distinct things: devices and connections. A device is a physical interface like wlp2s0 or eth0. A connection is a named profile containing settings like IP address, DNS, and security keys. A device can exist without an active connection. A connection can exist without a device. The goal is to bind a connection to a device and activate it.
Think of NetworkManager like a power strip with smart plugs. The devices are the physical outlets. The connections are the settings for each plug, including voltage, timing, and label. You can have a plug configured for a lamp, but if the lamp is not plugged in, the setting does nothing. Conversely, you can have a lamp plugged in with no configuration, and NetworkManager might ignore it.
NetworkManager also hands off DNS information to systemd-resolved by default. This means /etc/resolv.conf is usually a symlink to a stub file managed by systemd. Reading the real file directly often gives stale or misleading data. Use resolvectl to see what the system actually resolves.
Check the device state before the connection state. An unmanaged device breaks everything downstream.
Check status and state
Verify the daemon is running and the device is managed.
systemctl status NetworkManager
# Check if the service is active. If it is inactive, the network stack is unmanaged.
# Look for "Active: active (running)" in the output.
# systemctl status shows recent log lines and state in one view. Always check status before restarting.
Map the hardware to the configuration profiles.
nmcli device status
# List all network interfaces and their current state.
# "disconnected" means no active connection. "unmanaged" means NetworkManager ignores this device.
# "connected" means a connection profile is active on the device.
nmcli connection show
# List all saved connection profiles.
# The "NAME" column is what you use to bring connections up or down.
# The "DEVICE" column shows which hardware the profile is currently bound to.
Wi-Fi configuration
Connect to a wireless network via the command line.
nmcli device wifi list
# Scan for available access points.
# Requires the Wi-Fi device to be in the "connected" or "disconnected" state, not "unmanaged".
# If the device is unmanaged, check for conflicting configuration in /etc/NetworkManager/conf.d/.
nmcli device wifi connect "SSID" password "wepassword"
# Create a new connection profile and activate it immediately.
# NetworkManager saves the credentials in /etc/NetworkManager/system-connections/.
# The profile name defaults to the SSID. Use --name to override.
Static IP and advanced settings
Configure a static IP address on an existing connection.
nmcli connection modify ens3 \
ipv4.method manual \
ipv4.addresses 192.168.1.50/24 \
ipv4.gateway 192.168.1.1 \
ipv4.dns "1.1.1.1 8.8.8.8"
# Change the IP configuration method from DHCP to manual.
# Set the address with CIDR notation, gateway, and DNS servers.
# This edits the profile. The changes do not apply until the connection is reactivated.
# ipv4.method accepts "auto" for DHCP, "manual" for static, or "disabled" for no IPv4.
Reactivate the connection to apply the new settings.
nmcli connection up ens3
# Reactivate the connection to apply the new static IP settings.
# This brings the interface down and back up with the modified profile.
# If the connection is already active, this forces a reconfiguration.
Reload and apply changes
Apply changes made to connection files without restarting the service.
nmcli connection reload
# Reread connection profiles from disk.
# Use this after editing files in /etc/NetworkManager/system-connections/ directly.
# Avoids a full daemon restart which drops all active connections.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. NetworkManager connection files live in /etc/NetworkManager/system-connections/.
Verify the configuration
Confirm the network state matches expectations.
nmcli device show
# Display detailed state for all devices.
# Check "IP4.ADDRESS[1]" for the assigned IP and "IP4.DNS[1]" for DNS servers.
# Look for "GENERAL.STATE" to confirm the device is "connected".
resolvectl status
# Show the full DNS configuration per interface.
# This reflects the data NetworkManager passed to systemd-resolved.
# More reliable than checking /etc/resolv.conf on Fedora.
# Look for "DNS Servers" and "Domains" under the relevant interface section.
Trust the resolver output. /etc/resolv.conf lies on modern Fedora.
Common pitfalls and errors
If nmcli device status shows a device as unmanaged, NetworkManager is ignoring it. This often happens when a legacy /etc/network/interfaces file exists or when managed=false is set in a keyfile. Remove the conflicting configuration or set the device to managed.
The command nmcli connection up may fail with Error: Connection activation failed: No suitable device found for this connection. This means the connection profile specifies an interface name that does not match the current hardware. Check the interface-name property in the profile against the output of nmcli device status.
If you can ping IP addresses but not domain names, DNS is broken. Fedora uses systemd-resolved by default. NetworkManager updates the resolver dynamically. If you see Failed to resolve errors, check resolvectl status to ensure the DNS servers are listed and not marked as DNSSEC: no.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. NetworkManager interacts heavily with SELinux contexts. A denial here usually means a mislabeled file, not a broken daemon.
Read the journal before guessing. journalctl -xeu NetworkManager tells you exactly which property failed validation.
When to use NetworkManager vs alternatives
Use nmcli when you need to manage connections from the command line or script network changes. Use nmtui when you prefer a text-based interface for quick configuration without memorizing flags. Use the GNOME Settings GUI when you are managing a desktop and want visual feedback for Wi-Fi and VPN connections. Use ip commands only when you need to manipulate the kernel network stack directly, such as adding temporary routes or aliases that NetworkManager should not manage. Use systemd-networkd when you are running a minimal server without a display manager and want to avoid the NetworkManager dependency. Stay on NetworkManager for standard Fedora Workstation and Server installations.
NetworkManager is the default for a reason. Stick with it unless you have a specific constraint.