NetworkManager is the default network management daemon that ships with Fedora 44. It does a great job on desktops and laptops where Wi-Fi networks change constantly. But on a headless server, a homelab box, or a production environment with a static IP, NetworkManager often creates more problems than it solves — overwriting your /etc/resolv.conf, adding boot delays through NetworkManager-wait-online.service, and sometimes conflicting with tools like cPanel or custom network bridges.
This guide shows you exactly how to disable NetworkManager on Fedora 44 and replace it with systemd-networkd, which is lighter, more predictable, and already built into every Fedora installation. You will get step-by-step commands, an explanation of what each command does and why it matters, and a full troubleshooting section at the end.
Whether you are running a Fedora 44 VPS, a bare-metal homelab server, or a minimal install you want to keep clean, this Linux server tutorial walks you through the entire process safely.
What Is NetworkManager and Why Does It Cause Problems on Servers?
NetworkManager is a daemon built for dynamic network environments. It monitors available connections, automatically switches between Wi-Fi networks, manages VPN tunnels, and handles hotspot configurations. For a developer on a laptop, those features are genuinely useful.
On a server, those same features become liabilities. NetworkManager polls for network changes constantly, adds services to the boot sequence that can stall startup by 15 to 20 seconds, and occasionally rewrites DNS configuration files that you have manually set. If you have ever configured a static IP on Fedora only to find it partially working after a reboot, there is a good chance NetworkManager quietly changed something.
The alternative, systemd-networkd, is part of the systemd project and ships with Fedora 44 by default. It reads simple .network configuration files, applies them at boot, and then stays out of the way. No polling. No background management. No surprises.
Here is a quick comparison to help you decide which tool fits your situation:
| Feature | NetworkManager | systemd-networkd |
|---|---|---|
| Wi-Fi and WLAN support | Full support | Not supported natively |
| Boot time impact | Adds 15-20 seconds | Minimal |
| Static IP configuration | Can conflict | Reliable and clean |
| DNS management | Automatic | Manual via systemd-resolved |
| Best for | Desktop / Laptop | Server / Headless system |
| Memory footprint | Higher | Very low |
If your system is a server or does not need Wi-Fi management, systemd-networkd is the right tool. The rest of this guide assumes that is your situation.
Prerequisites
Before you run a single command, gather the following information and make sure your environment is ready. Skipping this step is the most common reason a server ends up unreachable after a network service change.
System requirements:
- Fedora 44 installed (Server, Minimal, or Workstation spin)
- Root access or a user account with full
sudoprivileges systemd-networkdpackage (pre-installed on Fedora 44)- Physical console access, a VM snapshot, or a second SSH session open as a safety net
Information to collect before starting:
- Your current network interface name (e.g.,
enp1s0,eth0) - Your current IP address (static or DHCP)
- Your default gateway
- Your DNS server addresses
Run these three commands right now and save the output somewhere:
ip addr show
ip route show
cat /etc/resolv.confAlso run this to see all NetworkManager connection profiles:
nmcli connection showSave everything to a text file:
nmcli connection show > ~/nm-backup.txt
ip addr show >> ~/nm-backup.txt
ip route show >> ~/nm-backup.txt
cat /etc/resolv.conf >> ~/nm-backup.txtThis backup file is your safety net. If something goes wrong, you have the exact configuration needed to restore connectivity manually.
Step 1: Update Your Fedora 44 System Before Making Changes
Always update your system before making changes to core services. This prevents a scenario where a pending update to a NetworkManager package undoes your work right after you complete it.
sudo dnf update -yWhy this matters: Package updates can re-enable or restart services. Running dnf update first means you are starting from a clean, current state and no pending NM update will interfere after you disable it.
After the update completes, reboot if the kernel was updated:
sudo rebootOnce your system is back online, confirm you are running Fedora 44:
cat /etc/os-releaseExpected output:
NAME="Fedora Linux"
VERSION="44 (Server Edition)"Step 2: Check the Current Status of NetworkManager
Before you stop NetworkManager, confirm it is actually running and note its current state. This gives you a clear before-and-after reference point.
systemctl status NetworkManagerExpected output:
● NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; preset: enabled)
Active: active (running) since ...The key fields here are enabled and active (running). Both will change after you complete this tutorial.
Also check which network interfaces NetworkManager currently manages:
nmcli device statusExpected output:
DEVICE TYPE STATE CONNECTION
enp1s0 ethernet connected Wired connection 1
lo loopback unmanaged --Note the DEVICE name in the first column, in this example enp1s0. You will need this exact name later when creating a systemd-networkd configuration file. Every system uses a different interface name, so do not assume yours matches this example.
Step 3: Configure systemd-networkd BEFORE Stopping NetworkManager
This is the most important step in the entire process. Configure your replacement network service first, before you touch NetworkManager. If you stop NetworkManager without a working replacement in place, your server will immediately lose network connectivity. On a remote server, that means a locked-out machine.
Step 3.1: Unmask systemd-networkd
On some Fedora 44 installs, systemd-networkd is masked by a system preset that favors NetworkManager. Unmask it first so you can enable and start it.
sudo systemctl unmask systemd-networkdWhy: A masked service is linked to /dev/null. Even systemctl enable fails on a masked service. Unmasking restores the normal service unit file so systemd can use it.
Step 3.2: Create a .network Configuration File
The .network file tells systemd-networkd how to configure your network interface. Create it now, before disabling NM, and use the interface name you recorded in Step 2.
sudo mkdir -p /etc/systemd/network
sudo nano /etc/systemd/network/10-eth0.networkFor a static IP setup, paste the following and replace the values with your actual network settings:
[Match]
Name=enp1s0
[Network]
Address=192.168.1.100/24
Gateway=192.168.1.1
DNS=8.8.8.8
DNS=1.1.1.1For DHCP, use this instead:
[Match]
Name=enp1s0
[Network]
DHCP=ipv4Save the file: press Ctrl+O, then Enter, then Ctrl+X.
Why the [Match] section matters: systemd-networkd applies .network files based on the Name= value in the [Match] block. If the name does not exactly match your real interface name, the file is silently ignored and your interface gets no IP address after NM is gone.
Step 3.3: Set Up systemd-resolved for DNS
When NetworkManager is running, it writes DNS server addresses to /etc/resolv.conf automatically. Once NM is gone, nothing writes to that file unless you set up a replacement. systemd-resolved handles DNS resolution and integrates cleanly with systemd-networkd.
Enable and start it now:
sudo systemctl enable systemd-resolved
sudo systemctl start systemd-resolvedThen create the symlink that tells the system to use systemd-resolved for all DNS lookups:
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.confWhy the symlink is required: Most applications read DNS servers from /etc/resolv.conf. By pointing this file to systemd-resolved‘s stub resolver, all DNS queries route through systemd-resolved correctly. Without this step, DNS lookups fail even when the network interface itself is fully configured.
Step 3.4: Enable and Start systemd-networkd
Now bring systemd-networkd online:
sudo systemctl enable systemd-networkd
sudo systemctl start systemd-networkdWhy enable AND start: enable adds systemd-networkd to the boot sequence so it runs automatically after every reboot. start brings it online right now in the current session without requiring a reboot, so you can verify it works immediately.
Confirm it is running:
systemctl status systemd-networkdExpected output:
● systemd-networkd.service - Network Configuration
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled)
Active: active (running)Step 4: Stop NetworkManager
With systemd-networkd now running and your .network file in place, it is safe to stop NetworkManager. Your interface should remain configured because systemd-networkd already owns it.
sudo systemctl stop NetworkManagerWhy this is safe now: systemd-networkd has already applied the IP configuration from your .network file. Stopping NM does not drop your connection because a different service is now managing the interface.
Verify your connection is still active after stopping NM:
ip addr show
ping -c 3 google.comIf both commands succeed, your IP address is intact and DNS is working. You can proceed to the next step with confidence.
Step 5: Disable NetworkManager at Boot
stop only kills NM for the current session. On the next reboot, systemd will start it again because it is still enabled. Remove it from the boot sequence with disable.
sudo systemctl disable NetworkManagerAlso disable the companion service that causes boot delays:
sudo systemctl disable NetworkManager-wait-online.serviceWhy disable NetworkManager-wait-online.service separately: This service waits for NetworkManager to bring interfaces online before other services can start. Without NetworkManager running, this service either stalls or causes a timeout that delays your boot by 15 to 20 seconds. Disabling it separately is required because it has its own systemd unit file.
Verify both are disabled:
systemctl is-enabled NetworkManager
systemctl is-enabled NetworkManager-wait-online.serviceBoth commands should return disabled.
Step 6: Mask NetworkManager to Prevent Any Accidental Restart
disable removes the autostart symlink, but NM can still start if another service or a package update triggers it. On a production server, that is unacceptable. Masking goes one level further.
sudo systemctl mask NetworkManagerWhy masking is the final lock: mask replaces the service unit with a symlink to /dev/null. When systemd sees a unit file pointing to /dev/null, it refuses to start that service under any circumstances, regardless of what triggers it. Even sudo systemctl start NetworkManager will fail with a clear error.
Also mask the dispatcher service, which runs scripts in response to NM network events:
sudo systemctl mask NetworkManager-dispatcher.serviceVerify the masked state:
systemctl status NetworkManagerExpected output:
● NetworkManager.service
Loaded: masked (/dev/null; masked)
Active: inactive (dead)Step 7: Verify the Complete Network Configuration
With NetworkManager disabled and masked and systemd-networkd running, do a full verification before you close your terminal session.
Step 7.1: Check Interface Status with networkctl
networkctl listExpected output:
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp1s0 ether routable configuredThe configured status in the SETUP column means systemd-networkd successfully applied your .network file. If you see unmanaged, the interface name in your .network file does not match the real interface name.
For detailed interface information:
networkctl status enp1s0Step 7.2: Verify IP Address and Default Gateway
ip addr show
ip route showConfirm the IP address matches what you configured in your .network file and that the default gateway is correct.
Step 7.3: Test DNS Resolution
resolvectl query google.com
ping -c 3 google.comBoth commands must succeed. resolvectl query tests DNS resolution through systemd-resolved. ping tests end-to-end connectivity including routing. If ping works but resolvectl query fails, the /etc/resolv.conf symlink from Step 3.3 needs to be re-applied.
How to Keep a Specific Interface Unmanaged Without Disabling NetworkManager Entirely
Some users want NetworkManager to keep managing Wi-Fi but want to remove its control from a specific Ethernet interface, for example a dedicated NIC used for a VM bridge or a server VLAN. You can do that without fully disabling NM.
Create a drop-in configuration file:
sudo nano /etc/NetworkManager/conf.d/99-unmanaged-devices.confAdd the following, replacing enp2s0 with your interface name:
[device-enp2s0-unmanaged]
match-device=interface-name:enp2s0
managed=0Save and reload NetworkManager:
sudo systemctl reload NetworkManagerWhy this works: NetworkManager reads all .conf files from /etc/NetworkManager/conf.d/ at startup and when reloaded. Setting managed=0 tells it to skip that interface entirely, leaving kernel-level or systemd-networkd control in place for that NIC while NM continues managing everything else.
For a quick temporary test without persistence:
sudo nmcli device set enp2s0 managed noThis setting disappears after a reboot unless backed by the .conf file above.
Troubleshooting: Common Errors When Disabling NetworkManager on Fedora 44
Error 1: Interface Shows “unmanaged” in networkctl list
Symptom: networkctl list shows your interface as unmanaged with no IP address.
Cause: The Name= value in your .network file does not match the real interface name.
Fix: Run ip link show to get the exact interface name, then edit your .network file to match:
ip link show
sudo nano /etc/systemd/network/10-eth0.network
sudo systemctl restart systemd-networkdError 2: No IP Address After Reboot
Symptom: System boots, but ip addr show shows no IP on your main interface.
Cause: Your .network file is in the wrong directory, or systemd-networkd is not enabled.
Fix:
ls /etc/systemd/network/
systemctl is-enabled systemd-networkd
sudo systemctl enable --now systemd-networkdError 3: DNS Stops Resolving After Disabling NetworkManager
Symptom: ping 8.8.8.8 works but ping google.com fails.
Cause: /etc/resolv.conf is no longer managed by NM and the systemd-resolved symlink is broken or missing.
Fix:
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
resolvectl query google.comError 4: SSH Session Drops When Stopping NetworkManager
Symptom: Running sudo systemctl stop NetworkManager immediately kills your SSH connection.
Cause: You stopped NM before systemd-networkd was configured. NM removed the IP assignment from the interface when it stopped, and no replacement service reapplied it.
Fix: If you have console access, configure and start systemd-networkd first, then stop NM. Always complete Steps 3 and 4 in that exact order.
Error 5: NetworkManager Restarts After a dnf Update
Symptom: After sudo dnf update, NetworkManager is running again even though you disabled it.
Cause: You disabled NM but did not mask it. A package update triggered a service restart via a post-install scriptlet.
Fix:
sudo systemctl stop NetworkManager
sudo systemctl mask NetworkManager
sudo systemctl mask NetworkManager-dispatcher.serviceHow To Roll Back and Re-enable NetworkManager on Fedora 44
If something goes wrong or your use case changes and you need NetworkManager back, here is the complete rollback procedure. Run these commands from a console or an active SSH session that still has connectivity.
sudo systemctl unmask NetworkManager
sudo systemctl unmask NetworkManager-dispatcher.service
sudo systemctl enable --now NetworkManager
sudo systemctl stop systemd-networkd
sudo systemctl disable systemd-networkdThen restore DNS management to NetworkManager:
sudo rm /etc/resolv.conf
sudo systemctl restart NetworkManagerWhy remove /etc/resolv.conf first: NetworkManager regenerates this file automatically when it starts, but only if the file does not already exist or is not a symlink pointing elsewhere. Removing the systemd-resolved symlink clears the path for NM to write fresh DNS settings.
After NM restarts, verify it is managing your interface again:
nmcli device status
ip addr show