标题Ubuntu 22.04 虚拟机网卡显示 unmanaged 无法联网根因不是 ifupdown是 netplan 少写了一行摘要虚拟机里 Ubuntu 22.04 的 ens33 一直显示 unmanaged改managedtrue、重启 NetworkManager、跑netplan apply全都没用。排查两天后发现真根因是 —— netplan 的 yaml 里没有声明任何接口导致它生成的托管授权文件是0 字节NetworkManager 因此认为自己无权接管所有网卡。本文完整记录排查路径、三层根因和可复制的修复命令。标签建议Ubuntu / Linux / 网络配置 / NetworkManager / netplan / 虚拟机 / VMware分类Linux / 运维Ubuntu 22.04 虚拟机网卡显示 unmanaged 无法联网根因不是 ifupdown是 netplan 少写了一行前言事情是这样的VMware 里的 Ubuntu 22.04 虚拟机突然上不了网。nmcli device status一看网卡ens33状态是unmanaged未托管。然后就是经典的踩坑循环改/etc/NetworkManager/NetworkManager.conf里的[ifupdown] managedtrue→没用sudo systemctl restart NetworkManager→没用回退 netplan 配置到官方默认 →还是没用sudo nmcli device connect ens33→Error: ... because device is strictly unmanaged折腾了很久才发现真正的根因藏在一个几乎没人会去看的文件里而它的大小是0 字节。这篇文章把完整排查路径和根因写清楚希望能帮你少走两天弯路。一、故障现象现象命令输出网卡未被托管nmcli device statusens33 ethernet unmanaged --拒绝连接nmcli device connect ens33because device is strictly unmanaged无 IPip addr show ens33只有 MAC没有inet行链路关闭ip link show ens33BROADCAST,MULTICAST缺UP和LOWER_UP上不了网ping/apt update不通 / 「暂时不能解析域名」二、环境项值宿主机Windows VMware Workstation虚拟机Ubuntu 22.04 Server/Desktop网卡ens33VMware 虚拟网卡网络模式NAT网段192.168.52.0/24网关192.168.52.2网络管理栈netplan → NetworkManager含 ifupdown 兼容插件三、排查过程第 1 步先排除虚拟机层这一步千万别跳sudoiplinksetens33 upiplinkshow ens33输出2: ens33: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP ...拿到UP,LOWER_UP和qdisc fq_codel说明物理链路完全正常VMware 虚拟交换机没问题。这一步的价值立刻把问题范围从是不是虚拟机设置错了缩小到问题 100% 在 Guest 系统内部。很多人卡在这里反复折腾 VMware 的网络编辑器纯属浪费时间。第 2 步发现 ifupdown 插件的嫌疑但这是个陷阱cat/etc/NetworkManager/NetworkManager.conf[main] pluginsifupdown,keyfile [ifupdown] managedtrue [device] wifi.scan-rand-mac-addressno[ifupdown] managedtrue已经是对的但问题在pluginsifupdown,keyfile这一行。原理NetworkManager 有个兼容插件叫ifupdown用来和老式的/etc/network/interfaces共存。它的逻辑是读 /etc/network/interfaces ├─ 文件存在 → 逐条标记这些网卡归 ifupdown我不碰局部让位 └─ 文件不存在 → 我不知道 ifupdown 想管哪些 → 全部别碰全局让位而Ubuntu 18.04 之后/etc/network/interfaces默认就不生成了改用 netplan于是这个插件每次启动都扫描失败直接进入“全局让位”。这里有个大坑很多人看到配置文件里已经有[ifupdown] managedtrue就以为是设好的。但这两个开关层级完全不同[main] pluginsifupdown,keyfile ← 插件级决定要不要加载 ifupdown 插件 [ifupdown] managedtrue ← 条目级只对已被 ifupdown 声明过的网卡生效managedtrue对一个空集合做操作等于什么都没做。真正决定全局状态的是plugins那一行。于是我改成[main] # pluginsifupdown,keyfile pluginskeyfile⚠️ 注意必须改写不能注释掉plugins。这个键是必填项注释掉之后 NetworkManager 会 fallback 回编译时的默认值——而 Ubuntu 编译时默认就是ifupdown,keyfile等于白改。重启验证pluginskeyfile已生效NetworkManager --print-config21|head-40第 3 步改完插件后仍然 unmanaged问题还在。这说明 ifupdown 不是唯一甚至不是主要原因。第 4 步找到那个 0 字节的文件 ⭐这是整件事的转折点。检查 NetworkManager 的配置目录ls-la/etc/NetworkManager/conf.d/# 只有 default-wifi-powersave-on.conf正常ls-la/run/NetworkManager/conf.d/# -rw-r--r-- 1 root root 0 9月 24 20:02 10-globally-managed-devices.conf# ↑ 大小是 0文件存在但是 0 字节。再看 netplan 的输入cat/etc/netplan/*.yaml# Let NetworkManager manage all devices on this systemnetwork:version:2renderer:NetworkManager没有ethernets:段没有声明任何接口。到这里真根因浮出水面netplan 只在 yaml 里显式声明了具体接口时才会往/run/NetworkManager/conf.d/10-globally-managed-devices.conf写入托管授权内容[keyfile]unmanaged-devicesnone。yaml 里只有version和renderer、没有接口 → netplan 把这个文件创建出来但什么都不写→ NetworkManager 拿不到允许托管的显式授权 →所有设备被判为 unmanaged。这个设计很隐蔽空文件看起来像没有限制实际上含义恰恰相反 ——没有显式授权 不许托管。第 5 步补上接口声明# Let NetworkManager manage all devices on this systemnetwork:version:2renderer:NetworkManagerethernets:ens33:dhcp4:trueoptional:trueoptional: true的作用这块网卡不是开机必需的。不加的话如果网卡初始化慢systemd 会卡在waiting for network开机多等一两分钟。虚拟机里建议加上。这里我又踩了一个坑详见第七节坑 1 —— 照抄某篇文章的代码块结果optional缩进错了netplan generate直接报错。第 6 步生效sudochmod600/etc/netplan/01-network-manager-all.yamlsudonetplan generatecat/run/NetworkManager/conf.d/10-globally-managed-devices.conf# 这次有内容了sudosystemctl daemon-reloadsudosystemctl stop NetworkManagersudorm-f/var/lib/NetworkManager/NetworkManager.statesudosystemctl start NetworkManagersleep3sudoiplinksetens33 upsleep2nmcli device status结果DEVICE TYPE STATE CONNECTION ens33 ethernet connected netplan-ens33 lo loopback unmanaged --通了。四、根因总结三层拦截现象unmanaged在三层里完全一样所以你没法靠“看现象”区分 —— 必须找到能区分的观测点。① ifupdown 插件层 NetworkManager.conf 里 pluginsifupdown,keyfile /etc/network/interfaces 不存在Ubuntu 18.04 默认不生成 → 插件扫描失败 → 进入“全局让位” → 所有设备 unmanaged ② netplan 授权层 ★ 真根因 yaml 里没有声明任何接口 → netplan 生成 0 字节的 10-globally-managed-devices.conf → NetworkManager 拿不到托管授权 → 全部 unmanaged ③ 状态缓存层 /var/lib/NetworkManager/NetworkManager.state 缓存了“不托管”的决定 → 只改配置不清它NM 启动时沿用旧决定 → 改了也白改用来区分三层的关键观测点cat/run/NetworkManager/conf.d/10-globally-managed-devices.conf空文件 / 不存在→ 命中 ②netplan 没授权去改 YAML有unmanaged-devicesnone→ ① 或 ③ 有问题查插件和状态缓存五、完整修复流程可直接抄Step 1 — Netplan 显式声明接口最关键/etc/netplan/01-network-manager-all.yamlnetwork:version:2renderer:NetworkManagerethernets:ens33:dhcp4:trueoptional:truesudochmod600/etc/netplan/01-network-manager-all.yamlsudonetplan generate网卡名不一定是ens33用ip link或ls /sys/class/net/确认自己的。Step 2 — 去掉 ifupdown 插件/etc/NetworkManager/NetworkManager.conf[main] # pluginsifupdown,keyfile pluginskeyfileStep 3 — 显式授权双保险sudomkdir-p/etc/NetworkManager/conf.dsudotee/etc/NetworkManager/conf.d/10-globally-managed-devices.conf/dev/nullEOF [keyfile] unmanaged-devicesnone EOFunmanaged-devices是黑名单none 一个都不排除全都管* 全排除都别管。Step 4 — 清状态缓存并重启sudosystemctl daemon-reloadsudosystemctl stop NetworkManagersudorm-f/var/lib/NetworkManager/NetworkManager.statesudosystemctl start NetworkManagersleep3sudoiplinksetens33 upsleep2nmcli device statusStep 5 — 分层验证ipaddr show ens33# 1. IPiproute# 2. 默认路由ping-c3192.168.52.2# 3. 网关ping-c3223.5.5.5# 4. 外网 IP跳过 DNSping-c3www.baidu.com# 5. 域名验 DNS逐层过。哪层断就在哪层治比一把梭快得多。六、几个容易踩的坑坑 1YAML 缩进 —— 别照抄博客的代码块我参考的某篇博客里代码块是这样的注意这是错的ethernets: ens33: ← 4 空格 dhcp4: true ← 6 空格 optional: true ← 4 空格 ← 错和 ens33 平级了照抄之后netplan generate报/etc/netplan/01-network-manager-all.yaml:8:15: Error in network definition: expected mapping (check indentation)为什么错YAML 的父子关系完全靠缩进表达没有括号。optional: true缩进 4 格就和ens33:平级了YAML 于是认为它是ethernets的另一个子项而ethernets.*的值必须是一段配置mapping却收到一个标量true→ 报expected mapping。正确写法optional是接口级属性必须和dhcp4同级ethernets:ens33:← 4 空格dhcp4:true ← 6 空格optional:true ← 6 空格和 dhcp4 对齐顺带一个超实用的报错定位技巧文件:行:列: Error in network definition: expected mapping (check indentation)报错的列号指向的是「值」的起始位置不是行首。用它反推缩进层级一找一个准optional: true 123456789012345 ↑ 第 15 列 true 的起点反推值在第 15 列 → 前面optional:加空格占 13 列 → 缩进只有 4 格 → 比该在的位置浅了 2 格。快速修法sudosed-i8s/^/ //etc/netplan/01-network-manager-all.yaml还有两条 YAML 硬规则缩进只能用空格绝对不能用 Tab从网页复制代码块是最常见的 Tab 来源冒号后面必须有空格dhcp4: true✅ /dhcp4:true❌排错神器cat -n -A 文件——^I是 Tab$是行尾。没有^I却报缩进错说明问题在层级深浅不在 Tab通用教训看博客里的 YAML按语义核对层级别按像素照抄。判断口诀问「这个键是描述谁的」optional/dhcp4描述某块网卡→ 挂在网卡名:下renderer/version描述整个网络→ 挂在network:下坑 2lo显示 unmanaged 是正常的DEVICE TYPE STATE CONNECTION ens33 ethernet connected netplan-ens33 lo loopback unmanaged -- ← 正常别当线索NetworkManager永不托管回环接口这是设计如此。我排查时一度把它当成NM 主进程有问题的证据走了弯路。坑 3ICMPping≠ DNS 可用性修好之后验证出现一个诡异现象ping 192.168.52.2 → 0% loss ✅ ping 223.5.5.5 → 100% loss ❌ ping www.baidu.com → 0% loss 7.7ms ✅223.5.5.5不通但www.baidu.com能通关键DNS 走 UDP/TCP 53ping 走 ICMP完全两回事。www.baidu.com那条能通说明它先成功做了 DNS 解析解析到220.181.111.232再发出 ICMP—— 这两步都成功等于证明 IP 层、路由层、NAT、DNS 全链路正常。223.5.5.5不通的原因查证该 IP 正常是可 ping 的实测 0% 丢包、平均 12.4ms所以不是阿里封了 ICMP而是本地出口链路对它做了过滤—— 部分校园网 / 企业网会对非本机构的公共 DNS 做 ICMP 丢弃属于策略而非故障。结论这个 ping 失败无害不要被它带偏。要验证 DNS 是否可用应该用nslookupwww.baidu.com# 或直连某个 DNS 测试nslookupwww.taobao.com223.5.5.5坑 4nmcli device set dev managed yes只是临时的只改运行时状态重启即失效。必须从配置层解决。坑 5设备Device≠ 连接Connection设备 device连接 connection是什么内核里的网络接口NM 保存的配置档案例子ens33、lo、docker0Wired connection 1、netplan-ens33存在哪内核不在文件系统/etc/NetworkManager/system-connections/手建/run/NetworkManager/system-connections/netplan 生成nmcli delete能删吗不能物理网卡会报 “not a software device”能nmcli connection delete ens33删的是档案不是网卡而且解决不了 unmanaged。另外看到netplan-xxx命名的连接不要删那是 netplan 生成的。七、排查命令速查# 1. 先排除虚拟机层最关键别跳iplinkshow ens33# 要看到 UP,LOWER_UP# 2. 看设备归属nmcli device status# 注意 lo 是 unmanaged 属正常# 3. 看 NM 实际解析出的配置NetworkManager --print-config21|head-40# 4. ⭐ 看授权文件有没有内容区分不同原因的关键观测点cat/run/NetworkManager/conf.d/10-globally-managed-devices.conf# 5. 看 netplan 输入是否声明了接口cat/etc/netplan/*.yaml# 6. 看配置覆盖源ls-la/etc/NetworkManager/conf.d/ /usr/lib/NetworkManager/conf.d/第 4 步空文件 → 修 netplan补ethernets:有内容仍 unmanaged → 查 ifupdown 插件和状态缓存。八、总结不是网卡坏了是没人授权 NetworkManager 去管它。netplan 的 YAML 里没有声明任何接口 → 生成的托管授权文件是 0 字节 → NetworkManager 认为自己无权接管 → 所有设备判为 unmanaged。把ethernets: ens33:显式写进 YAML授权文件才有内容网络随即恢复。这次的教训有三条现象相同 ≠ 原因相同。要找到能区分不同原因的那个观测点—— 本例里就是那个 0 字节的授权文件。配置文件里看起来对不等于层级对。[ifupdown] managedtrue明明写对了但它在错误的层级上。YAML 的缩进就是语法本身。别照抄网页代码块按语义核对层级。如果以上都试过还是不行VMware Server/Minimal 镜像下 NM 有时真的救不回来可以直接换systemd-networkd绕过 NM 那一整套历史包袱sudosystemctl disable--nowNetworkManagersudosystemctlenable--nowsystemd-networkd systemd-resolved# netplan renderer 改 networkd或直接写 /etc/systemd/network/20-ens33.network# [Match] Nameens33# [Network] DHCPyes纯 CLI/服务器场景networkd 的明文 INI 配置比 netplan NM 插件 状态缓存这一串更好预测。参考资料虚拟机异常关机导致 Ubuntu 22.04 ens33 status: down —— 显式声明接口 unmanaged-devicesnone 清状态重启的思路来源Debian Wiki — NetworkManager —— ifupdown / unmanaged 机制说明Fixing Unmanaged Network Interfaces on Ubuntu Linux —— 状态缓存必须清除Use NetworkManager to Handle ‘Device Not Managed’ ——lo显示 unmanaged 属正常如果这篇文章帮你解决了问题点个赞让更多人看到。有别的排查思路也欢迎在评论区交流。