Docker守护进程不提供全局umask配置，需在容器启动阶段设置：通过环境变量UMASK由entrypoint解析、在Dockerfile中固化（如写入/etc/profile.d/）、或用启动命令显式执行umask命令；umask影响新文件（0666 & ~umask）和目录（0777 & ~umask）权限，且必须为三位或四位八进制数。
Docker 守护进程本身不直接提供全局 umask 配置项，它不会像 shell 那样在启动容器时自动设置进程的 umask 值。容器内进程的 umask 默认继承自镜像中启动程序（如 /bin/sh、/sbin/init 或应用主进程）所处环境的初始值，而该值通常由基础镜像（如 alpine、debian）在构建时固化，或由容器启动命令间接影响。
但你可以在容器启动阶段可控地设置 umask，关键不是改 Docker daemon 配置，而是通过以下三种方式之一，在容器运行前或运行时生效：
umask如何影响容器内映射文件的权限
当容器内程序（如 nas-tools 的下载器、重命名脚本）创建新文件或目录时，其权限由：
- 文件：
0666 & (~umask) - 目录：
0777 & (~umask)
决定。
例如UMASK=0022→ 新建文件为644（-rw-r--r--），目录为755（drwxr-xr-x）；
而UMASK=0002→ 文件664，目录775，利于组内协作写入。
在容器启动时设置 umask 的有效方式
-
通过环境变量传入并由入口脚本解析（推荐）
多数成熟镜像（如jxxghp/nas-tools）已支持UMASK环境变量。它会在容器启动时被 entrypoint 脚本读取，并执行umask $UMASK。
✅ 示例（docker run）：-e UMASK=0002
✅ 示例（docker-compose.yml）：
environment: - UMASK=0002
这会作用于容器内所有后续由该 shell 启动的子进程（包括 nas-tools 主程序及其调用的
cp、mkdir、touch等）。 -
在 Dockerfile 中固化 umask（适用于自定义镜像）
若你基于官方镜像构建自己的版本，可在Dockerfile中写：RUN echo "umask 0002" >> /etc/profile.d/umask.sh && \ chmod +x /etc/profile.d/umask.sh或更直接地：
SHELL ["sh", "-c", "umask 0002 && exec \"$@\"", "sh"]
⚠️ 注意：
SHELL指令会影响所有后续RUN和CMD，需谨慎使用。 -
通过启动命令显式设置（适用于调试或一次性场景）
docker run -it --rm -v $(pwd)/data:/data jxxghp/nas-tools \ sh -c "umask 0002 && exec /app/nas-tools"
此方式绕过镜像原有 entrypoint，适合验证
umask效果，但不便于长期维护。
为什么不能在 /etc/docker/daemon.json 里设 umask
Docker daemon 配置（如 default-ulimits、insecure-registries）控制的是守护进程自身行为或容器运行时资源限制，不干预容器内用户进程的文件创建上下文。umask 是进程级属性，必须在容器命名空间内、用户态启动流程中设置，无法由 daemon 全局注入。
验证 umask 是否生效
进入运行中的容器：
docker exec -it nas-tools sh umask # 应输出你设定的值，如 0002 touch /tmp/testfile && mkdir /tmp/testdir ls -ld /tmp/testfile /tmp/testdir # 查看实际权限是否符合预期
不复杂但容易忽略：UMASK 必须是三位八进制数（如 002、022、0002），前导零不可省略；且仅对容器内新创建的文件/目录生效，不影响已存在文件的权限。
