Fix NetworkManager Device Unmanaged on Linux

nmcli device status lists your Ethernet NIC as unmanaged while enp0s3 stays connected. NetworkManager will not apply DHCP, static IP, or DNS on that interface until something marks it managed again or removes the rule that excluded it.

The steps below read the NM reason code, find config or legacy settings that block management, put the device back under NM control, and confirm the connection profile is active.

What unmanaged means in NetworkManager

A managed device gets an IP from an active connection profile — DHCP, static settings, VLAN, or bridge membership. An unmanaged device is visible to NM but excluded from that workflow.

Unmanaged is not the same as a cable unplugged. The link can be up and an old IP may still show in ip addr, but nmcli connection up and GUI network tools will not configure that NIC until you fix the managed flag or the unmanaged-devices rule.

Check device state with nmcli

List every interface and its NM state:

nmcli device status

When enp0s8 is excluded from management, the STATE column shows unmanaged:

DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
enp0s8  ethernet  unmanaged               --
lo      loopback  connected (externally)  lo

CONNECTION is -- because no profile can attach to an unmanaged device.

Read the numeric state and reason NetworkManager recorded:

nmcli -f GENERAL.STATE,GENERAL.REASON,GENERAL.NM-MANAGED,GENERAL.CONNECTION device show enp0s8

After nmcli device set enp0s8 managed no, the reason text names the user decision:

GENERAL.STATE:                          10 (unmanaged)
GENERAL.REASON:                         75 (The device is unmanaged by explicit user decision (e.g. 'nmcli device set $DEV managed no'))
GENERAL.NM-MANAGED:                     no
GENERAL.CONNECTION:                     --

GENERAL.NM-MANAGED: no is the quick flag to confirm NM is not driving this interface. Note the REASON number — it narrows the next section to config file versus manual managed no.

Check NetworkManager configuration

Persistent unmanaged rules usually live in drop-in files under /etc/NetworkManager/conf.d/. List them:

ls /etc/NetworkManager/conf.d/

An empty directory means no local overrides — check /usr/lib/NetworkManager/conf.d/ for package-installed snippets (containers, virtualization, or CNI tools often add unmanaged-devices there).

Create this lab rule to reproduce a config-driven unmanaged NIC:

sudo tee /etc/NetworkManager/conf.d/99-lab-unmanaged.conf >/dev/null <<'EOF'
[keyfile]
unmanaged-devices=interface-name:enp0s8
EOF

Reload NetworkManager so it rereads configuration:

sudo nmcli general reload

Check the device again:

nmcli -f GENERAL.STATE,GENERAL.REASON,GENERAL.NM-MANAGED device show enp0s8

GENERAL.STATE:                          10 (unmanaged)
GENERAL.REASON:                         76 (The device is unmanaged by user decision via settings plugin ("unmanaged-devices" for keyfile or "NM_CONTROLLED=no" for ifcfg-rh))
GENERAL.NM-MANAGED:                     no

Reason 76 points at unmanaged-devices in a keyfile snippet or NM_CONTROLLED=no in a legacy ifcfg profile. Remove the lab file before you continue on a real host:

sudo rm /etc/NetworkManager/conf.d/99-lab-unmanaged.conf

The main file rarely lists devices directly — snippets override it:

grep -E '^unmanaged-devices|^\[keyfile\]' /etc/NetworkManager/NetworkManager.conf

Package snippets can match wildcards (interface-name:docker*, interface-name:cali*). When a new NIC name matches, it becomes unmanaged even though you never edited /etc yourself.

Check whether another service manages the interface

NetworkManager should be the only daemon applying profiles on RHEL, Rocky, AlmaLinux, Fedora, and most Ubuntu desktop installs. Confirm nothing else owns layer-3 config:

systemctl is-active systemd-networkd

inactive

On RHEL-family hosts, the legacy network init script service is the other common owner — check it the same way:

systemctl is-active network

inactive

inactive on both means the legacy network service and systemd-networkd are not fighting NM on this host.

On older RHEL layouts, check for NM_CONTROLLED=no in ifcfg files:

grep -H NM_CONTROLLED /etc/sysconfig/network-scripts/ifcfg-* 2>/dev/null

No output on RHEL 10 with keyfile-only profiles is normal — connections live under /etc/NetworkManager/system-connections/ instead.

If you use netplan on Ubuntu Server, /etc/netplan/*.yaml can define interfaces outside NM. Pick one stack: either move the interface into NM or disable NM for that NIC — not both.

Manual ip addr add or a custom ifup script can also leave an IP on the wire while NM shows unmanaged; that does not mean NM is managing the host.

Configure the interface as managed

Pick the fix that matches the REASON from device show.

Reason 75 (explicit managed no): allow NM to control the NIC again:

sudo nmcli device set enp0s8 managed yes

Reason 76 (unmanaged-devices or NM_CONTROLLED=no): edit or remove the matching line in /etc/NetworkManager/conf.d/*.conf or the ifcfg file, then reload:

sudo nmcli general reload

If a profile existed before the device went unmanaged, bring it back:

sudo nmcli connection up enp0s8

connection up fails with "device not managed" until the managed flag and config snippets are fixed — run managed yes and reload first.

For a NIC that never had a profile, create one (adjust addresses for your LAN):

sudo nmcli connection add type ethernet ifname enp0s8 con-name enp0s8 ipv4.method auto

Activate the new profile once the device is managed:

sudo nmcli connection up enp0s8

Restart or reload NetworkManager

nmcli general reload rereads connection profiles and conf.d snippets without dropping every interface — prefer it after editing unmanaged-devices:

sudo nmcli general reload

When state still looks stale, reload the systemd unit:

sudo systemctl reload NetworkManager

A full restart is a heavier hammer over SSH — it can bounce the interface carrying your session:

sudo systemctl restart NetworkManager

Use restart only when reload does not clear unmanaged state after config changes. On a single SSH path, prefer reload, then nmcli device reapply enp0s8 on the affected NIC only.

After marking the device managed, reapply pushes the active profile to the kernel without a daemon restart:

sudo nmcli device reapply enp0s8

Connection successfully reapplied to device 'enp0s8'.

Verify with nmcli

Confirm the device left unmanaged state:

nmcli device status

DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
enp0s8  ethernet  connected               enp0s8
lo      loopback  connected (externally)  lo

STATE connected and a profile name in CONNECTION mean NM is managing the NIC again.

Double-check the managed flag and reason cleared:

nmcli -f GENERAL.STATE,GENERAL.REASON,GENERAL.NM-MANAGED device show enp0s8

GENERAL.STATE:                          100 (connected)
GENERAL.REASON:                         0 (No reason given)
GENERAL.NM-MANAGED:                     yes

Confirm the kernel has an address on the interface:

ip -4 addr show enp0s8

inet 192.168.56.116/24 brd 192.168.56.255 scope global dynamic noprefixroute enp0s8

A quick reachability test on the LAN confirms traffic leaves the managed interface:

ping -c2 -W2 192.168.56.220

PING 192.168.56.220 (192.168.56.220) 56(84) bytes of data.
64 bytes from 192.168.56.220: icmp_seq=1 ttl=64 time=0.968 ms
64 bytes from 192.168.56.220: icmp_seq=2 ttl=64 time=2.94 ms

--- 192.168.56.220 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

If ping fails after the device shows connected, move to network is unreachable or destination host unreachable — unmanaged was not the only problem.

Troubleshooting

References

• NetworkManager.conf(5) — unmanaged-devices and [keyfile] section
• nmcli(1) — device status, device set managed, general reload
• nm-settings-keyfile(5) — keyfile plugin and device flags
• Red Hat — Configuring NetworkManager — managed devices on RHEL family

Summary

An unmanaged NetworkManager device is excluded from connection profiles — nmcli device status shows unmanaged and GENERAL.NM-MANAGED no even when the link is up. DHCP, DNS, and nmcli connection up do nothing until you remove the block.

Start with nmcli device show DEVICE and read GENERAL.REASON. Reason 75 means you (or a script) ran nmcli device set DEVICE managed no; reason 76 means unmanaged-devices in a conf.d file or NM_CONTROLLED=no in legacy ifcfg. Search /etc/NetworkManager/conf.d/ and package snippets under /usr/lib/NetworkManager/conf.d/, and confirm systemd-networkd or legacy network is not managing the same interface.

Set managed yes, delete the matching unmanaged-devices line, run nmcli general reload, then connection up or device reapply. Verify with nmcli device status showing connected, an active CONNECTION name, and a working ping on the LAN. If routing errors remain after the NIC is managed, continue with the network is unreachable guide.