最近在公司做微服务迁移，团队把原本跑在物理机上的服务全搬进了 Docker 容器。本以为一切顺风顺水，结果上线第二天就有同事反馈：某个配置文件写不进去，日志一直报 Permission Denied。
查了半天才发现，问题出在容器内的文件创建权限上——根本不是代码或配置错了，而是容器启动时的环境掩码（umask）没设对。
什么是 umask？
简单说，umask 就是“权限过滤器”。它决定了新创建的文件和目录默认能有多大访问权限。比如你在容器里用应用账号新建一个日志文件，默认可能是 666 权限（所有人可读写），但 umask 会从中“减掉”一部分。
常见的 umask 值是 022，意思是去掉组和其他用户的写权限，最终文件变成 644。如果是 002，就只去掉其他人的写权限，保留组内可写，适合多用户协作场景。
为什么容器里更要关心 umask？
很多镜像基于 Alpine 或 Debian 构建，默认 umask 可能是 022，但如果你的应用以非 root 用户运行，又需要往特定目录写数据，这时候权限很容易出问题。
比如我们那个出问题的服务，启动脚本里用 su - appuser 切换用户，但没设置 umask，导致生成的日志文件权限是 600，而监控工具作为另一个用户根本读不了。
怎么设置容器里的 umask？
最直接的方式是在启动命令前加 umask 设置：
docker run myapp sh -c 'umask 002 && exec /usr/local/bin/start-server.sh'或者在 Dockerfile 里写进启动脚本：
ENV UMASK=002
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]对应的 entrypoint.sh 内容：
#!/bin/sh
umask $UMASK
exec "$@"注意 shell 的加载顺序
有些同学喜欢在 .bashrc 或 .profile 里设 umask，但在容器里不一定生效。因为很多服务用 sh -c 直接执行，不会加载这些 profile 文件。
稳妥做法是显式在入口脚本中设置，不依赖 shell 自动加载机制。
实际建议
如果你的应用涉及多用户协作或需要被外部工具读取文件，推荐将 umask 设为 002，并确保主组正确。如果只是单应用专用，022 更安全。
别等到线上出问题才去翻权限设置，构建镜像时就把 umask 纳入考量，省得后期反复调试。