只读文件系统导致应用无法写入临时文件的根本原因是挂载路径（如/tmp、/run、/var/log）被设为只读且应用未适配可写路径；解决方法包括用tmpfs挂载内存目录、绑定主机可写目录替代只读挂载、以及代码层显式指定并校验可写路径。
只读文件系统开启后，应用无法写入临时文件是典型配置冲突问题。根本原因不是权限没设对，而是容器内需要写入的路径（如 /tmp、/run、/var/log）被整体或局部挂载为只读，而应用又没适配可写路径。
明确哪些目录必须可写
先停掉服务，检查应用行为：
- 日志是否默认输出到挂载目录（如
/app/logs或/var/log/app） - 是否依赖
/tmp存放 session、缓存、上传中转文件 - 是否在运行时生成 PID 文件、socket 文件（常放在
/run或/var/run）
用 tmpfs 挂载内存临时目录
这是最轻量、最安全的解法，适合无需持久化的临时数据：
- 在
docker-compose.yml中为服务添加：
services:
app:
# ... 其他配置
tmpfs:
- /tmp
- /run
- /var/run
- 若使用
docker run，加参数：--tmpfs /tmp --tmpfs /run - tmpfs 内容驻留内存，重启即清空，不占磁盘，且天然可写
绑定主机可写目录替代只读挂载点
当临时数据需跨重启保留（如某些缓存、调试日志），就用主机目录映射：
- 确保宿主机目标目录存在且权限正确（如属主为容器内 UID）：
mkdir -p /host/tmp /host/logs-
chown 1001:1001 /host/tmp /host/logs（1001 是容器内应用用户 UID） - 在 compose 中替换原只读挂载：
volumes: - /host/tmp:/tmp:rw - /host/logs:/var/log/app:rw - ./config:/etc/app:ro # 配置仍保持只读
代码层适配：别依赖默认路径
硬编码写入 Assembly.Location 或 AppContext.BaseDirectory 下的文件，在只读镜像里必然失败：
- 显式指定可写路径，例如通过环境变量传入：
-
DOTNET_TMP_DIR=/tmp或APP_DATA_DIR=/data - 启动容器时设置：
environment: { APP_DATA_DIR: "/tmp" } - 代码中优先使用
Path.GetTempPath()，但务必加一次写入校验（避免某些定制镜像连/tmp都只读）：
var testPath = Path.Combine(Path.GetTempPath(), "test-write");
try { File.WriteAllText(testPath, "x"); File.Delete(testPath); }
catch { throw new InvalidOperationException("Temp directory is not writable"); }
