You plug an Ethernet cable into a fresh Fedora install
The link light blinks green. You open a terminal and run ping 8.8.8.8. Nothing happens. The interface sits there, physically connected but logically invisible. This usually happens when NetworkManager marks the interface as unmanaged, or when the system is waiting for a DHCP lease that never arrives. You do not need to edit configuration files by hand. You just need to tell the network daemon what to do.
What's actually happening
Fedora ships with NetworkManager as the default network daemon. It watches hardware interfaces, handles carrier detection, requests IP addresses via DHCP, and applies routing rules. When you insert a cable, the kernel detects the link state. NetworkManager reads that signal and decides whether to bring the interface up. If the interface shows as disconnected, unmanaged, or available, NetworkManager is actively ignoring it for a specific reason.
The daemon separates physical state from logical state. A cable being plugged in is physical. Getting an IP address and joining a subnet is logical. NetworkManager handles the logical side. If it refuses to act, the configuration or the hardware state is mismatched. The system does not guess. It waits for explicit instructions or a matching profile. NetworkManager uses a state machine to track interfaces. The unmanaged state means the daemon has been explicitly told to ignore the hardware. The disconnected state means the hardware is visible but no active profile is bound to it. The connected state means an IP is assigned and routing is active. Understanding which state you are in dictates which command you run next.
Run journalctl -xeu NetworkManager before you guess. The log will show whether the failure is a driver issue, a missing firmware blob, or a configuration conflict. Read the actual error before guessing.
The fix or how-to
Start by checking what NetworkManager sees. Run the status command to list every interface and its current state.
nmcli device status
# Lists all network interfaces recognized by the kernel
# Shows the DEVICE, TYPE, STATE, and CONNECTION columns
# STATE tells you if the interface is connected, disconnected, or unmanaged
If the interface shows as disconnected, bring it up explicitly. NetworkManager sometimes waits for a user action before requesting an IP. You can activate it directly through the device command.
nmcli device connect enp3s0
# Replaces enp3s0 with your actual interface name from the previous step
# Forces NetworkManager to attempt a connection immediately
# Triggers DHCP client negotiation if no static IP is configured
If you need a static IP instead of DHCP, create a new connection profile. Profiles are the configuration objects NetworkManager uses. They survive reboots and hardware changes. The profile name is arbitrary, but the interface binding must be correct.
nmcli connection add type ethernet con-name office-lan ifname enp3s0
# Creates a new profile named office-lan bound to the specified interface
# type ethernet tells NetworkManager to expect a wired link
# ifname ensures the profile only activates on the correct hardware
nmcli connection modify office-lan ipv4.addresses 192.168.1.50/24
# Sets the static IPv4 address and subnet mask
# The /24 notation tells the system the network boundary is 255.255.255.0
nmcli connection modify office-lan ipv4.gateway 192.168.1.1
# Defines the default route for outbound traffic
nmcli connection modify office-lan ipv4.dns "8.8.8.8 8.8.4.4"
# Adds primary and secondary DNS resolvers
nmcli connection modify office-lan ipv4.method manual
# Switches the profile from DHCP to static configuration
nmcli connection up office-lan
# Activates the newly created profile immediately
Convention aside: NetworkManager stores profiles in /etc/NetworkManager/system-connections/. Never edit those files directly while the daemon is running. Use nmcli or nmtui to modify them. Direct edits cause race conditions and silent failures. Trust the package manager and the daemon. Manual file edits drift, snapshots stay.
Verify it worked
Check the active connection and verify routing. The system should show the interface as connected and list the correct IP assignment.
nmcli connection show --active
# Displays only profiles that are currently bound to an interface
# Confirms the profile name and the interface it controls
ip route show default
# Verifies the default gateway matches your network topology
# An empty output means routing is broken even if the link is up
ping -c 4 8.8.8.8
# Sends four ICMP echo requests to test external connectivity
# Packet loss here indicates a routing or firewall issue, not a link issue
If the ping succeeds but domain names fail, your DNS configuration is incomplete. NetworkManager passes DNS settings to systemd-resolved. Check the resolver status with resolvectl status. Reboot before you debug. Half the time the symptom is gone after a clean daemon restart.
Common pitfalls and what the error looks like
Interface names change between boots if biosdevname or net.ifnames is enabled. You might see enp3s0 today and enp2s0 tomorrow. Bind the connection to a MAC address or use a persistent name. NetworkManager handles this automatically when you specify ifname, but hardware swaps can still break the binding. DHCP servers sometimes hand out slow leases. NetworkManager times out after thirty seconds by default. You can extend the timeout in the profile. Run nmcli connection modify office-lan ipv4.dhcp-timeout 60000 to give the server sixty seconds. The value is in milliseconds.
SELinux rarely blocks NetworkManager, but if you see denials in journalctl -t setroubleshoot, restore the context on /etc/NetworkManager/ with restorecon -Rv. The daemon expects specific file contexts to read profiles securely. If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name. Check the hardware list with ip link. If the interface is missing entirely, the kernel driver or firmware is not loaded. Run dnf upgrade --refresh to pull the latest kernel and firmware packages. dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them.
Run journalctl -xe first. Read the actual error before guessing.
When to use this vs alternatives
Use nmcli when you are working over SSH or need scriptable, repeatable network configuration. Use nmtui when you prefer a terminal-based menu but still want NetworkManager to handle the backend. Use the GNOME Network settings GUI when you are managing a desktop and want visual feedback. Use raw ifcfg files only when you are maintaining legacy infrastructure that predates NetworkManager. Stay on nmcli for servers and headless machines.