umask不是设置默认权限，而是从文件起点666、目录起点777中按位屏蔽权限：文件实际权限=666−umask，目录=777−umask；需用touch/mkdir实测并比对计算结果排查偏差。
直接看当前 umask 值和新建文件的实际权限，再比对计算逻辑是否匹配——这是排查的核心动作。umask 本身不报错，异常往往藏在“预期 vs 实际”的落差里。
确认当前会话的 umask 值
运行以下命令，获取真实生效的掩码：
-
umask—— 输出八进制值（如0022） -
umask -S—— 输出符号格式（如u=rwx,g=rx,o=rx），更直观对应权限位
注意：不同 shell 或子进程可能继承不同 umask。如果问题只出现在某个服务（如 Tomcat、Nginx、Python 脚本）中，需在该进程内部检查。例如，在 Tomcat 的 catalina.sh 中常有显式设置 UMASK 变量；Java 应用则可能通过启动脚本或 JVM 参数间接影响。
验证新建文件/目录的权限是否符合 umask 计算逻辑
不要依赖记忆中的“默认值”，动手测试最可靠：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 执行
touch testfile && mkdir testdir - 运行
ls -l testfile testdir，观察实际权限 - 对照计算公式验证：
- 文件：
666 & ~umask→ 如 umask=002，则666 & ~002 = 664（rw-rw-r--） - 目录：
777 & ~umask→ 同例得775（rwxrwxr-x）
- 文件：
若实测结果与计算不符，说明有更高优先级机制介入（如 ACL、应用层显式 chmod、容器环境覆盖等）。
检查是否存在覆盖 umask 的配置或行为
umask 可被多层覆盖，需逐级排查：
-
用户级配置：检查
~/.bashrc、~/.profile、~/.bash_profile中是否有umask行；非登录 shell（如脚本执行）可能读~/.bashrc，登录 shell 读~/.profile -
系统级配置：查看
/etc/profile、/etc/bash.bashrc（Debian/Ubuntu）、/etc/login.defs（影响新用户创建时的默认 umask） -
服务/应用级覆盖：Tomcat 的
catalina.sh、systemd service 文件中的UMASK=或Environment=UMASK=...、Docker 容器启动参数--umask（v24.0+） -
ACL 干预：若目标目录设置了默认 ACL（
setfacl -d），它会与 umask 共同作用，优先级高于 umask 单独生效。可用getfacl /path查看是否有default:条目
区分文件类型与创建方式的影响
不是所有“新建文件”都走 umask 流程：
-
touch、shell 重定向>、fopen("file","w")等由 shell 或 libc 触发的创建，受 umask 控制 -
cp、git checkout、install、IDE 新建文件、容器内ADD指令等，通常复制源文件权限或使用硬编码权限，忽略 umask - 脚本文件（
.sh）默认无执行位：即使 umask=000，touch a.sh得到仍是644，因为内核强制文件起始权限为666（不含 x）
若发现某类文件权限异常但其他正常，重点检查其创建路径是否绕过了 umask 机制。
