登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

findmnt 怎样识别 overlay 挂载的上层目录

来源:17golang原创

时间:2026-10-24 22:35:38 167浏览 收藏

排查 OverlayFS 文件“明明写成功了,却在宿主机找不到”时,关键不是盯着 SOURCE,而是查看目标挂载的 OPTIONS。对 overlay 类型的挂载,upperdir=/path 才是可写上层目录;lowerdir 是只读层,workdir 是 OverlayFS 的工作目录。

最稳妥的判断方式是先用 findmnt --kernel --target 锁定挂载点,再显式输出 OPTIONS,从其中读取 upperdir=。不要把显示为 overlay 的 SOURCE 误认为实际上层路径。
  • 先看目标:确认查询的路径确实落在 overlay 挂载上。
  • 再看选项:固定输出列,避免依赖默认表格顺序。
  • 最后拆分:只匹配 upperdir=,并注意当前 mount namespace。

官方资料:https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html

findmnt 手册:https://www.man7.org/linux/man-pages/man8/findmnt.8.html

影响面:SOURCE 为什么不能直接当 upperdir

OverlayFS 把一个或多个 lower 目录与 upper 目录合并成一个可见的 merged 目录。用户访问的是 merged 挂载点,修改文件时,内核可能把对象复制到 upper 层。此时 findmnt 的 SOURCE 只是在挂载表中描述来源的字段,不能替代 upperdir 的挂载参数。

先针对目标路径筛选文件系统,并固定显示关键列:

# 先锁定目标挂载,再把来源和文件系统选项分开显示
findmnt --kernel --target /merged \
  --output TARGET,FSTYPE,SOURCE,OPTIONS

如果 FSTYPE 不是 overlay,说明查询路径当前没有直接落在 OverlayFS 挂载上;如果是 overlay,继续检查 OPTIONS 中是否出现 upperdir=。

时间线:先固定输出,再定位 upperdir

故障现场最容易出现的误判是:默认输出被截断,或者把 SOURCE 一列复制成了上层目录。findmnt 手册建议脚本显式指定输出列,因此排查和后续自动化都应固定列名。

findmnt 查询 overlay 挂载时 TARGET、FSTYPE、SOURCE 与 OPTIONS 的字段关系说明图
图1:静态结构说明图,展示 findmnt 的目标筛选、字段分组以及 upperdir 所在的 OPTIONS 关系;不是终端截图。
# 输出 JSON 便于脚本读取;/merged 替换为实际挂载点
findmnt --kernel --target /merged --json \
  --output TARGET,FSTYPE,OPTIONS

JSON 适合交给脚本继续处理,但不要假设字段顺序或默认输出结构。若只需要人工快速判断,表格输出已经足够;若要纳入巡检,建议保留 --output 和 --kernel。

触发条件:从 OPTIONS 中提取真正的上层目录

OPTIONS 是逗号分隔的选项集合。不要用“包含 upper”这种宽松匹配,因为 lowerdir、workdir 和其他参数也可能出现在同一行。下面的写法只识别以 upperdir= 开头的单个选项:

# 逐个拆分挂载选项,只打印 upperdir= 后的路径
findmnt --kernel --target /merged --noheadings \
  --output OPTIONS |
awk -F, '{
  # 选项可能位于任意位置,不能只取第一个逗号字段
  for (i = 1; i 

如果没有输出,不要直接判定 OverlayFS 没有上层目录:只读 overlay 可以省略 upperdir 和 workdir,此时它本来就没有可写上层。另一方面,路径中可能包含转义内容,自动化脚本应把输出当作路径字段处理,而不是自行猜测目录结构。

OverlayFS 的 upperdir、lowerdir、workdir 与 merged 挂载点静态关系图
图2:静态结构说明图,展示 upperdir、lowerdir、workdir 与 merged 目录之间的配置关系;不是运行结果或截图。

根因与修复:别忘了 mount namespace

findmnt --kernel 默认读取当前进程的 /proc/self/mountinfo。如果目标挂载在容器或其他 mount namespace 中,宿主机直接查询可能看不到相同的 upperdir。可以针对仍在运行的进程查看其命名空间:

# 在目标进程的 mount namespace 中查询同一个挂载点
findmnt --task 1234 --kernel --target /merged \
  --output TARGET,FSTYPE,SOURCE,OPTIONS

这里的 PID 只是示例,实际应替换成目标进程号。确认 namespace 后,再把 upperdir 与 lowerdir、workdir 一起记录:内核文档要求 workdir 与 upperdir 位于同一文件系统,不能只凭 upperdir 一项推断整个 OverlayFS 配置。

防复发:一张速查表

现象优先检查结论
SOURCE 显示 overlayOPTIONS 是否含 upperdir=SOURCE 不是上层目录
没有 upperdir 输出FSTYPE、OPTIONS、是否只读可能是只读 overlay 或查错挂载
宿主机查不到容器路径--task PID先确认 mount namespace
多层 lowerdirlowerdir 与 merged 关系可见文件不一定来自 upperdir

把这套判断固化成脚本时,固定 --kernel、--target 和 --output,并对没有 upperdir 的情况返回“只读或需进一步确认”,不要把空值当成某个默认目录。

常见问题

findmnt 的 SOURCE 是什么?

它是挂载表中的来源字段,不能直接等同于 OverlayFS 的 upperdir。上层目录应从 OPTIONS 中的 upperdir= 读取。

为什么查到 overlay 却没有 upperdir?

可能是只读 overlay,也可能是当前进程所在的命名空间或目标路径不对。先固定 FSTYPE、TARGET、OPTIONS,再用 --task 排除 namespace 差异。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>