非 root 用户运行 Docker 容器时权限问题核心在于用户身份、文件属主、挂载路径三者未对齐，典型表现为 Permission denied、No such file or directory、Read-only file system 等错误，需分别验证文件归属、行尾格式、UID 匹配及日志目录预创建。
非 root 用户运行 docker 容器时，报错往往不直接指向权限，而是表现为“文件找不到”“拒绝访问”“启动即退出”等现象。核心问题在于用户身份、文件属主、挂载路径三者之间未对齐。下面按典型错误代码和表现，给出可立即验证的分析路径与修复动作。
Permission denied 错误（常见于 entrypoint.sh 或配置文件）
这不是宿主机权限问题，而是容器内进程以非 root 用户运行时，无法读取或执行属主为 root 的文件。
- 检查镜像中关键文件归属：运行 docker run --rm -it
ls -l /entrypoint.sh ，确认输出中用户列是否为你指定的非 root 用户（如 appuser） - 修复方式：在 Dockerfile 中用 COPY --chown=appuser:appuser entrypoint.sh /entrypoint.sh，并在 RUN 阶段确保该用户已创建
- 补充：如果使用多阶段构建，注意第二阶段中用户上下文是否继承；避免 COPY 后再用 chown 命令——会增加镜像层且易遗漏
No such file or directory（尤其出现在 shebang 行）
表面是文件缺失，实则常因 CRLF 行尾或解释器路径不匹配。非 root 用户环境更敏感，因为默认 shell 可能不是 bash。
- 验证行尾：进入容器执行 cat -A /entrypoint.sh | head -n1，若看到 ^M，说明是 Windows 换行
- 检查解释器是否存在：运行 docker run --rm -it
which bash ，Alpine 镜像通常只有 /bin/sh，应改用 #!/bin/sh - 修复建议：开发时统一设置编辑器换行为 LF；CI 流水线中加入 dos2unix entrypoint.sh 步骤（需先 apt install dos2unix 或 apk add dos2unix）
Read-only file system 或 Operation not permitted
当容器挂载了宿主机目录（如 -v /host/data:/app/data），而该目录在宿主机上由 UID 1001 拥有，但容器内应用以 UID 1000 运行时，就会触发此错误。
- 快速确认：在容器内运行 id 查看实际 UID，再用 ls -ld /app/data 看目录属主 UID 是否一致
- 两种可靠解法：
– 构建时固定 UID：RUN adduser -u 1001 -D appuser，使容器用户 UID 与宿主机目录一致
– 启动时动态映射：使用 --user 1001:1001 覆盖默认用户，无需修改镜像 - 注意：不要依赖 user:group 名称匹配，Linux 权限检查只认 UID/GID 数字
Failed to open log file /var/log/app.log: Permission denied
日志目录未预创建或属主不对，非 root 用户无法在 /var/log 下自动创建文件。
- 最佳实践：在 Dockerfile 中显式创建日志目录并赋权，例如
RUN mkdir -p /var/log/myapp && chown appuser:appuser /var/log/myapp - 避免让应用自己创建目录：多数语言运行时（如 Node.js、Python logging）在权限不足时静默失败，不抛异常
- 若用 volume 挂载日志目录，确保宿主机对应路径已用 chown 1001:1001 /host/logs 设置好属主
