宿主机改为可写后，ReadWritePaths 服务仍报只读

服务启动时 /boot 是只读挂载；随后宿主机把它改为可写，配置了 ReadWritePaths=-/boot/EFI 的服务在重启前一直把目标文件系统报告为只读。systemd 253、Linux 6.1.46 的这一类场景，需要检查运行中服务的挂载视图。

ReadWritePaths= 不能让只读文件系统变成可写。Linux 写入还要求挂载点和承载它的文件系统 superblock 都没有只读限制；这个 unit 设置只控制服务视图中的前一层。

对照宿主机与实际进程看到的挂载

先读取 unit、当前属性和进程号，示例使用 fwupd.service，其他服务替换名称：

systemctl cat fwupd.service
systemctl show fwupd.service -p MainPID -p ProtectSystem -p ReadWritePaths
findmnt --target /boot/EFI --output TARGET,SOURCE,FSTYPE,OPTIONS

保存目标路径、实际文件系统和选项。错误是 Read-only file system 时，增加文件权限不会解除这层限制；若文件系统因错误被保护为只读，应先按存储恢复流程处理，不能强制改成可写。

在支持 findmnt --task 的 util-linux 环境中，可由有权限的管理员读取目标进程的挂载信息：

sudo findmnt --task 1234 --target /boot/EFI \
  --output TARGET,SOURCE,FSTYPE,OPTIONS

1234 必须换成已确认仍在运行的目标进程号，不能照抄，也不能使用 MainPID=0。实际写文件的是另一个工作进程时，核对那个进程。该选项读取 /proc/进程号/mountinfo；权限不足、进程已退出或工具不支持，都不能解释成“服务没有挂载”。

新挂载传播与重挂载标志变化不同

宿主机后续创建的挂载，通常可以出现在服务命名空间中；这与把已经存在的挂载从只读改为可写不是同一种变化。不能只看到主机上的 rw，就保证原服务里对应挂载也更新了。

还要区分配置文件和旧进程。systemctl cat 读取磁盘定义，show 显示管理器属性；两者都不能独自证明原进程当前看见的挂载标志。只执行 daemon-reload 不会重新创建正在运行的命名空间。

这类行为后来补充了文档说明，不能把文档所属版本当成运行时修复版本，或承诺“升级后自动同步所有重挂载”。

需要新视图时，安排服务重新启动

先确认宿主机目标文件系统确实应当可写，故障没有来自磁盘保护、只读设计或错误路径。保留 unit、drop-in 和原挂载配置，在允许中断的窗口停止当前业务后重启目标服务；固件更新等任务必须遵守自身的维护流程，不能边更新边重启。

如果同时修改了 unit，先重新加载定义，再重启。保留 ProtectSystem 等限制和窄范围可写例外，不要为了写一个目录关闭全部沙箱。重启后重新对照进程挂载，并从正常应用入口验证原来失败的写入；服务状态变成 active 不等于操作已恢复。

如果路径在服务中根本不可见，应另查家目录保护与选择性绑定；临时目录隔离则见PrivateTmp 文件在终端不可见。这两种情况不能只靠可写例外处理。

需要撤销配置时，恢复原 unit 和挂载安排，再按同样的停机条件重建服务视图。配置回退不会撤销应用已经写入的数据，应按业务自己的备份与恢复记录处理。