NetworkManager Keeps Crashing on Linux — 3 Fixes That Actually Work

You're running a Debian 12 server or an Ubuntu 22.04 workstation, and suddenly the internet drops. You check systemctl status NetworkManager and see it's dead. Restart it with systemctl restart NetworkManager, it works for 10 minutes, then dies again. Or maybe it won't even start.

What's actually happening here is that NetworkManager is crashing because of something specific — not just "random instability." I've seen this on real hardware (a ThinkPad X1 Carbon gen 9 and a Dell PowerEdge R740) and the causes are almost always one of these three things.

1. Corrupt or Conflicting Config in /etc/NetworkManager

This is the #1 cause. NetworkManager reads all .conf files in /etc/NetworkManager/conf.d/ and /etc/NetworkManager/NetworkManager.conf. If one of these has a typo or a duplicate key, the daemon panics.

Real scenario: You installed network-manager-config-connectivity-ubuntu on a Fedora 38 system. That package drops a config file that expects a different backend. NetworkManager starts, parses the file, and segfaults immediately.

How to check:

journalctl -u NetworkManager -b -1 --no-pager | grep -i "error\|fail\|warn"

Look for lines like:

NetworkManager[1234]: <warn> [1700000000] config: error loading config file /etc/NetworkManager/conf.d/99-overrides.conf: invalid key 'dhcp'

The fix:

1. Move all .conf files out of conf.d to a backup directory:

mkdir /root/nm_backup
mv /etc/NetworkManager/conf.d/*.conf /root/nm_backup/

2. Restart the service:

systemctl restart NetworkManager

3. If it starts clean, add files back one by one, restarting each time. The bad one will make it crash again.

The reason step 3 works is that NetworkManager loads configs in alphabetical order. A bad file in the middle won't corrupt the whole load — it'll just abort. By adding files one at a time, you isolate the offender.

Pro tip: Don't keep unused configs. If you're not using a custom DHCP client or a connectivity checker plugin, delete those files. Less garbage = fewer crashes.

2. Kernel Module Mismatch with the Wi-Fi or Ethernet Driver

This one shows up on laptops with Intel AX210 Wi-Fi cards or Realtek RTL8125 Ethernet. The kernel module and NetworkManager don't agree on how to handle power saving or firmware blobs.

Real scenario: You updated the kernel from 5.15 to 6.2 on Ubuntu 22.04. NetworkManager now crashes every time you connect to a 5 GHz SSID. The iwlwifi module loads, but there's a firmware mismatch. NetworkManager tries to query the card's capabilities, gets garbage back, and dies.

How to check:

dmesg | grep -i "iwlwifi\|r8169\|NetworkManager" | tail -20

You'll see lines like:

iwlwifi 0000:00:14.3: firmware: failed to load iwl-debug-yoyo.bin
NetworkManager[1234]: segfault at 0 ip 00007f... sp 00007f... error 4

The fix:

1. Check your current kernel and firmware version:

uname -r
dpkg -l | grep firmware-iwlwifi

2. Install the correct firmware package for your kernel:

sudo apt update && sudo apt install firmware-iwlwifi
sudo update-initramfs -u
reboot

3. If the problem persists, blacklist the module's power saving:

echo "options iwlwifi power_save=0" | sudo tee /etc/modprobe.d/iwlwifi-power-save.conf
sudo update-initramfs -u
reboot

Why does this work? Because some kernel modules ship with power saving enabled by default. NetworkManager tries to query the link status every few seconds, but the card is sleeping. The driver returns junk, NetworkManager can't handle it, and the process dies. Forcing power_save=0 keeps the card awake.

3. Conflict Between NetworkManager and systemd-resolved

This one is sneaky. NetworkManager wants to manage DNS resolution via /etc/resolv.conf. systemd-resolved also wants to manage it. If they don't agree on which one is the boss, the DNS stub resolver can crash NetworkManager.

Real scenario: You installed systemd-resolved on a server running NetworkManager 1.40. NetworkManager starts, tries to update /etc/resolv.conf, but resolved has it locked. NetworkManager can't write the file and crashes with a permission error or a parse failure.

How to check:

ls -la /etc/resolv.conf
cat /etc/resolv.conf

If it's a symlink to /run/systemd/resolve/stub-resolv.conf or /usr/lib/systemd/resolv.conf, that's the problem. Also check:

journalctl -u NetworkManager | grep -i "dns\|resolv"

You'll see:

NetworkManager[1234]: <warn> [1700000000] dns-mgr: could not commit DNS changes: failed to write /etc/resolv.conf: Permission denied

The fix — pick one approach:

Option A: Use NetworkManager as the DNS manager (recommended)

sudo systemctl disable --now systemd-resolved
sudo unlink /etc/resolv.conf
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
sudo systemctl restart NetworkManager

Option B: Let systemd-resolved be the boss

Edit /etc/NetworkManager/NetworkManager.conf and add:

[main]
dns=systemd-resolved

Then restart:

sudo systemctl restart NetworkManager

The reason option B works is that it tells NetworkManager to hand DNS off to resolved. NetworkManager stops touching /etc/resolv.conf entirely. But option A is cleaner if you don't need resolved's split-DNS features.

Quick-Reference Summary

Don't waste time restarting the service over and over. Check the logs, pick the fix that matches your symptoms, and you'll be back online in 5 minutes.