systemd.automount 怎样按需挂载文件系统

我第一次把大目录挂载交给 systemd 管理时，最容易混淆的是“自动挂载单元”和“真正的挂载单元”并不是同一个文件。想让目录在访问时再挂载，核心做法是让同一挂载点拥有一对名字对应的 .automount 与 .mount 单元：前者守住访问入口，后者描述真正的文件系统。

官方文档：https://freedesktop.org/software/systemd/man/latest/systemd.automount.html

下面用 /srv/data-archive 作为示例目录。示例里的设备标签、文件系统类型和参数需要替换成你的实际环境；文章中的结构图是静态说明图，不是某台主机的运行截图。

我先把 automount 和 mount 的边界理清

data-archive.automount 描述“哪个目录由自动挂载机制守护”，data-archive.mount 描述“访问发生后要挂载什么文件系统”。两者都映射到 /srv/data-archive，并且单元文件名要按 systemd 的路径转义规则保持对应。

访问 /srv/data-archive 时，systemd 会根据自动挂载点找到匹配的 mount 单元。这里的“触发”描述的是单元关系，不等于文章已经在本机执行过命令；真正部署前仍要用后面的检查命令确认命名和配置。

先用挂载路径生成稳定的单元名

不要手工猜复杂目录对应的单元文件名。对简单路径 /srv/data-archive，可以让 systemd-escape 负责转换并指定后缀：

# 把绝对挂载目录转换成 .automount 单元名，避免手工转义出错
systemd-escape --path --suffix=automount /srv/data-archive

# 同一挂载目录生成匹配的 .mount 单元名
systemd-escape --path --suffix=mount /srv/data-archive

示例预期得到 srv-data-archive.automount 与 srv-data-archive.mount 这一对名字。不同发行版或 systemd 版本的转义显示可能包含转义序列，生产配置以命令实际输出为准；关键不是文件名看起来是否短，而是两个后缀对应同一个 Where= 路径。

把按需策略和真实挂载分成两个单元

下面是最小的结构示例。把它们放到同一个 systemd 单元搜索目录中，并确保文件名与 Where= 对应：

# data-archive.automount：只描述哪个目录接受按需挂载
[Unit]
Description=按需挂载归档目录

[Automount]
# Where 必须是绝对路径，并与单元文件名表达同一个目录
Where=/srv/data-archive

[Install]
# 让 systemctl enable 有明确的启动目标
WantedBy=multi-user.target

# data-archive.mount：描述首次访问后要接入的文件系统
[Unit]
Description=归档文件系统

[Mount]
# 示例使用设备标签；实际环境可替换为 UUID 或其他稳定来源
What=/dev/disk/by-label/ARCHIVE
Where=/srv/data-archive
Type=xfs
Options=nodev,nosuid

[Install]
WantedBy=multi-user.target

这里的 Where= 是两份配置的连接点。.automount 不能替代 .mount，而 .mount 也不会自动获得“访问目录时才挂载”的语义；把职责拆开，排查时更容易判断是入口关系错了，还是挂载来源错了。

生产配置里我会把空闲卸载和权限一起收紧

按需挂载真正有价值的地方，是让不常用的文件系统保持未挂载状态，并把挂载点目录的创建权限写清楚。可以在自动挂载单元中增加空闲超时和目录模式：

# 在 data-archive.automount 的 [Automount] 中补充生产约束
[Automount]
Where=/srv/data-archive
# 空闲十分钟后允许 systemd 尝试卸载；0 表示关闭空闲超时
TimeoutIdleSec=10min

# 自动创建挂载点及父目录时使用较窄的权限
DirectoryMode=0750

TimeoutIdleSec= 控制空闲后的卸载尝试，不是“挂载十分钟后强制断开”。如果有进程仍持有文件，实际释放还要结合业务访问模式判断。DirectoryMode=0750 只约束 systemd 创建挂载点目录时的模式，不能替代文件系统自身的权限、ACL 或服务用户设计。

挂载参数也要按数据敏感度选择。示例中的 nodev,nosuid 只是常见的生产基线提示，是否适用取决于归档盘上是否需要设备文件或 setuid 行为；不要把它们当成对所有文件系统都无条件正确的答案。

发布前用 systemctl 和 findmnt 看关系

配置写好后，我会先检查单元是否能被 systemd 识别，再确认自动挂载点与真实挂载来源的关系：

# 重新加载单元文件，让 systemd 读取刚保存的配置
sudo systemctl daemon-reload

# 只启动自动挂载入口，不主动启动普通 mount 单元
sudo systemctl enable --now data-archive.automount

# 查看自动挂载单元本身的状态和最近日志
systemctl status data-archive.automount --no-pager

# 用挂载表确认目录、来源和参数是否符合预期
findmnt --target /srv/data-archive

检查时不要只看 active (running) 这一行。自动挂载单元处于活动状态，只能说明入口已被 systemd 接管；真正的文件系统是否已经挂上、来源是什么，要结合 findmnt --target 的结果判断。若业务允许，再由业务侧发起一次真实访问并观察对应 mount 单元的状态。

几个最容易踩到的边界

• 两个单元的路径不一致：.automount 和 .mount 必须围绕同一个挂载目录命名，两个文件里的 Where= 也要一致。
• 把依赖写在错误的单元里：automount 与 mount 是分开的。网络文件系统的网络依赖、设备依赖和挂载选项，应回到匹配的 mount 单元及其实际来源分析，不要在 automount 单元里盲目堆叠顺序依赖。
• 用普通用户服务管理系统 automount：Linux 上的 automount 支持需要特权，通常应由系统服务管理器或 root 的用户服务管理器负责；普通无特权用户服务并不适合直接承担这类系统挂载。
• 只看 enable 没看来源：enable 解决开机启用关系，不能证明 What= 指向的设备、标签或网络来源可用。

最后留一张可复用的检查清单

如果你的目标只是“访问目录时再挂载”，可以按下面的顺序收尾：先用 systemd-escape 生成同一目录的一对单元名，再让 .automount 保存 Where=、超时和目录模式，让 .mount 保存 What=、文件系统类型和挂载选项，最后用 daemon-reload、status 与 findmnt 分别确认入口、关系和来源。

这样处理的好处是职责边界很清楚：访问入口由 automount 管，真实文件系统由 mount 管，目录权限和空闲策略有明确归属。遇到问题时，先排除名称和 Where= 不匹配，再查来源与权限，通常比反复重启服务更快。

相关问题

systemd.automount 一定会在开机时挂载吗？不会。它首先建立自动挂载入口，匹配的 mount 单元通常在挂载点被访问时才被激活。

TimeoutIdleSec=0 代表什么？它会关闭空闲超时逻辑；是否设置超时要结合业务是否存在长时间打开文件的进程。

为什么目录能访问但 findmnt 没有预期来源？先检查访问的路径是否与 Where= 完全一致，再检查 mount 单元的 What=、Type= 和实际设备/网络来源。