umask 通过屏蔽默认权限位影响新建目录权限：目录默认777，umask 022得755；需在用户~/.profile中设置并生效，注意systemd/cron等场景需单独配置umask或显式声明。
Umask 是怎么影响新建目录权限的
umask 不是直接设置权限，而是“屏蔽”掉某些权限位。比如 umask 022 表示新建目录时，自动去掉组和其他人的写权限（即从默认的 777 中减去 022，得到 755）。关键点在于：目录默认基础权限是 777，文件是 666；umask 按位取反后与基础权限做 AND 运算——但你不用记这个逻辑，记住“umask 值越大，新建内容越保守”就行。
常见误区是以为设了 umask 002 就能让同组用户编辑所有新目录，结果发现 mkdir 出来的目录还是 755。这是因为 shell 启动时只读一次 umask，且普通用户无法覆盖系统级设置，必须确保它在用户登录后的 shell 环境中生效。
让特定用户每次登录都加载自定义 umask
不能改全局 /etc/profile 或 /etc/bash.bashrc，否则影响所有人。应该只改目标用户的 shell 初始化文件：
- 确认用户用的是 bash：检查
/etc/passwd中该用户最后一列，通常是/bin/bash - 编辑其
~/.bashrc（交互式非登录 shell）或~/.profile（登录 shell），推荐后者更可靠 - 在文件末尾加一行：
umask 002（允许同组写）或umask 007（仅用户+组可访问） - 执行
source ~/.profile立即生效，或新开终端验证：umask应输出对应八进制值
注意：如果用户用 zsh，得改 ~/.zshrc；SSH 直连有时走 login shell，有时不走，~/.profile 覆盖面更广。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
为什么 mkdir 权限没变？检查这三处
即使 umask 显示正确，新建目录仍可能是 755，大概率卡在这几个地方：
-
mkdir命令显式指定了权限，如mkdir -m 755 foo，会完全忽略 umask - 程序（比如 rsync、IDE、脚本）自己调用
mkdir()系统调用时传了固定 mode，绕过 shell umask - 用户属于多个组，而创建目录时所在工作目录的 setgid 位未开启，导致新目录的属组不是预期组（进而让 umask 的组权限失效）
验证方法：手动运行 mkdir testdir && ls -ld testdir，排除工具链干扰。如果这时权限仍不对，说明 umask 根本没生效。
systemd 用户服务或 cron 下 umask 不生效怎么办
systemd --user 服务和 cron 任务默认不读 ~/.profile，所以 umask 设置无效。解决方式很具体：
- systemd 用户服务：在 unit 文件里加
UMask=0002（注意是十进制写法，不是八进制）到[Service]段 - cron 任务：在 crontab 文件顶部加
SHELL=/bin/bash和UMASK=002（部分 cron 实现支持，如 Vixie cron；若不支持，就改命令本身：bash -c 'umask 002; mkdir ...'） - 脚本里别依赖环境 umask：开头显式写
umask 002，尤其当脚本可能被不同上下文调用时
最容易被忽略的是：umask 是进程级属性，子进程继承父进程的 umask，但一旦某个中间程序（比如 Python 的 os.mkdir()）没传 mode 参数，它才真正用上当前 umask；而很多高级封装（如 pathlib.Path.mkdir()）默认带 mode=0o777，照样绕过。
