服务在终端能写文件，启动后却报Read-only file system。先查宿主机挂载和服务自己的文件系统视图；遇到只读限制时，加写权限也未必有用。
先确定谁把目录变成只读
用journalctl -u report.service -b找到报错路径，再用findmnt -T /srv/report/state -o TARGET,OPTIONS查看宿主机挂载。用systemctl cat report.service检查覆盖文件中的ProtectSystem、ReadOnlyPaths和ReadWritePaths。宿主机可写不代表服务看到的目录也可写。
给持久数据安排专用目录
应用能改路径时，优先使用StateDirectory=report，并让应用使用STATE_DIRECTORY指向的目录；系统服务的常见路径是/var/lib/report。StateDirectory不负责自动迁移旧数据，停写、备份和属主核对都要先做。DynamicUser下应避免手动猜测实际目录映射。
只给必须保留的路径开例外
路径无法迁移时，在服务的覆盖片段中为确实需要写入的目录配置ReadWritePaths=/srv/report/state。确认路径存在且服务账号有权限。例外不能把底层只读文件系统变成可写，也不会增加Unix权限。避免开放整个/srv。
排除账号权限和启动顺序
文件系统可写时，再查服务账号对目录和上级路径的访问权限。若数据盘单独挂载，确保挂载先于服务启动，避免应用把文件误写到根盘上同名目录。
从服务自身验证写入
在萤光云或LightNode的独立实例核对发行版支持与应用行为，再在生产维护窗口执行sudo systemctl daemon-reload和服务重启。触发正常业务写入并检查日志与产物，同时确认无需写入的目录仍保留原限制。
FAQ
chmod能修只读挂载吗？ 不能，权限位与挂载状态是两层。
该关闭ProtectSystem吗？ 优先为必要目录配置最小写入范围。
ReadWritePaths会创建目录吗？ 不会；需确保路径存在。
迁移后旧文件会自动带过去吗？ 不会，按应用方案迁移。
手动写成功能证明修好吗？ 不能，应验证实际服务执行的写入。
温馨提示
若发现整个磁盘因I/O故障变为只读，先保存诊断记录并检查文件系统和磁盘健康，不要为了恢复写入强行重挂载。
