1. 权限不足这件事几乎每个 Linux 普通用户都踩过刚接手一台 Linux 服务器或者在自己虚拟机上折腾环境的时候很多人都会遇到一个非常典型的场景用普通账号登录想在自己的工作目录下建一个项目文件夹敲下mkdir myproject结果终端直接甩回来一句mkdir: cannot create directory myproject: Permission denied。这个报错信息看起来简单但背后牵扯的东西其实不少——目录权限位、属主属组、umask 默认掩码、父目录的执行权限、SELinux 策略、挂载选项甚至文件系统本身的只读状态任何一个环节出问题都会导致同样的报错。我这些年帮人排查这类问题没有一百次也有八十次发现一个规律大部分人第一反应是直接sudo mkdir建完再用chown改属主能用是能用但这属于绕过问题而不是解决问题。真正搞明白权限模型之后你会发现绝大多数情况下根本不需要提权普通用户完全可以在自己该有权限的地方正常创建目录。这篇内容就是把我自己踩过的坑、总结出来的排查路径和实操方法完整梳理一遍从最基础的权限位讲起一直到 SELinux、挂载参数这些容易被忽略的深层原因最后给出一套可以直接照着做的排查流程。不管你是刚接触 Linux 的新手还是已经用了几年但一直靠sudo硬扛的老用户只要你想彻底搞清楚为什么普通用户建不了文件夹以及怎么优雅地解决这篇内容都值得花时间看完。下面我会按照先理解模型、再定位问题、最后动手解决的顺序展开每一步都配上可以直接复制的命令和实际输出示例。2. 先把 Linux 目录权限模型彻底搞明白2.1 权限位到底控制的是什么Linux 的文件权限用rwx三个字符表示读、写、执行对应数字 4、2、1。对于目录来说这三个权限的含义和普通文件完全不一样这是很多人混淆的根源。目录的读权限r决定你能不能列出目录里的内容也就是ls能不能用写权限w决定你能不能在这个目录里创建、删除、重命名文件或子目录执行权限x决定你能不能进入这个目录cd以及访问目录内文件的元数据。关键点来了在目录里创建文件夹需要的是该目录的写权限和执行权限而不是目录本身的什么特殊属性。很多人以为我要建文件夹所以我要对新建的那个文件夹有权限这个理解是反的。你新建的文件夹属主默认就是你你当然有权限真正卡住你的是父目录有没有给你写和执行权限。举个例子假设/home/alice这个目录的权限是drwxr-xr-x属主是 alice属组是 alice。那么 alice 自己在这个目录下建文件夹完全没问题因为属主位是rwx。但如果换成 bob 登录bob 对/home/alice来说属于其他人other只有r-x权限没有写权限那 bob 执行mkdir /home/alice/test就会直接报 Permission denied。这就是最典型的权限不足场景。2.2 属主、属组和其他人的判定顺序Linux 判断一个用户对某个文件或目录有什么权限顺序是固定的先看这个用户是不是属主owner如果是就用属主权限位如果不是再看这个用户是不是属于该文件的属组group如果是就用属组权限位如果都不是才用其他人other权限位。这个顺序不能颠倒而且一旦匹配到某一级就停止不会叠加。这里有个特别容易踩的坑如果一个用户既是属主又在属组里系统只按属主权限算。还有一种情况用户属于多个附加组只要其中任何一个组匹配到文件的属组就按属组权限算。你可以用id命令查看当前用户的所有组id # 输出示例uid1001(bob) gid1001(bob) groups1001(bob),27(sudo),1002(dev)上面这个输出说明 bob 同时属于 bob、sudo、dev 三个组。如果某个目录的属组是 dev那 bob 就按属组权限位来判定。2.3 umask 如何影响新建目录的默认权限新建目录的默认权限不是凭空来的它由umask值决定。目录的基础权限是 777rwxrwxrwx减去 umask 值就是实际权限。大多数 Linux 发行版普通用户的默认 umask 是 022所以新建目录的权限是 777 - 022 755也就是drwxr-xr-x。root 用户的 umask 通常是 022 或 077。查看当前 umaskumask # 输出0022umask 是 022 意味着新建目录同组用户和其他人都只有读和执行权限没有写权限。这在多人协作场景下就会出问题你和同事在同一个组里你建的目录同事却没法往里写东西。解决办法要么改 umask比如设成 002要么用mkdir -m显式指定权限要么事后chmod gw。我个人的习惯是在共享项目目录里直接用mkdir -m 2775前面的 2 是设置 SGID 位保证新建的子目录自动继承父目录的属组这个后面会详细讲。2.4 父目录执行权限的连锁效应这是最隐蔽的一个坑。假设/data/project目录权限是drwxrwx---属主 alice属组 devbob 属于 dev 组。看起来 bob 应该有写权限对吧但如果/data这一级目录对 bob 没有执行权限bob 连/data/project都进不去更别说在里面建东西了。目录的执行权限x是通行证没有它路径上的任何一级都会把你挡住。你可以用namei命令一次性查看整条路径每一级的权限namei -l /data/project/subdir # 输出会列出 / /data /data/project /data/project/subdir 每一级的权限和属主这个命令在排查明明权限看着没问题却还是进不去的场景时特别好用强烈建议记住。我遇到过好几次用户说我把目录权限改成 777 了还是不行结果一namei发现是上层某一级目录没有x权限改下层根本没用。3. 定位问题一套可复用的排查路径3.1 第一步永远是看报错和当前身份遇到Permission denied先别急着改权限先确认两件事当前登录的是谁以及报错的具体路径是什么。很多人用sudo su切到 root 之后忘了切回来然后奇怪为什么普通用户操作不了其实当前就是 root问题根本不在权限。whoami # 确认当前用户 pwd # 确认当前所在目录 ls -ld /path/to/parent # 查看目标父目录的权限、属主、属组ls -ld这个组合很关键-d表示查看目录本身而不是目录内容-l是长格式。输出类似drwxr-xr-x 2 alice dev 4096 Jan 1 10:00 /path/to/parent从这一行就能读出属主是 alice、属组是 dev、权限是 755。3.2 第二步用 namei 检查整条路径前面提到的namei -l是排查路径权限的利器。它会从根目录开始逐级列出每一层的权限。如果中间任何一级对当前用户没有x权限问题就定位到了。实际输出大概长这样f: /data/project/subdir drwxr-xr-x root root / drwxr-xr-x root root data drwxrwx--- alice dev project drwxr-xr-x alice dev subdir从这份输出能一眼看出/data/project这一级对 other 没有权限如果当前用户既不是 alice 也不在 dev 组里那就会被挡在project这一层。3.3 第三步确认文件系统是否可写有时候权限位看着完全正常但文件系统本身是只读挂载的这种情况在容器环境、救援模式、或者磁盘出问题后自动 remount 成只读的场景下很常见。用mount或者findmnt查看挂载选项findmnt -T /path/to/parent # 输出会显示该路径所在的文件系统及挂载参数如果输出里能看到roread-only那不管你怎么改权限都没用得先解决挂载问题。另外磁盘满了df -h显示 100%也会导致创建失败但报错通常是No space left on device而不是 Permission denied不过有些文件系统在 inode 耗尽时也会报奇怪的错误顺手df -i看一眼 inode 使用情况没坏处。3.4 第四步排查 SELinux 和 ACL如果前面几步都正常权限位没问题、路径通畅、文件系统可写但还是建不了目录那就要考虑 SELinux 和 ACL 了。SELinux 在 CentOS、RHEL、Fedora 上默认开启它会在传统权限之外再加一层强制访问控制。查看 SELinux 状态getenforce # 输出 Enforcing / Permissive / Disabled如果是 Enforcing可以临时设成 Permissive 测试一下问题是否消失sudo setenforce 0如果设成 Permissive 后能建目录了那基本可以确定是 SELinux 策略问题需要看审计日志ausearch -m avc -ts recent来定位具体是哪条策略在拦。ACL 则用getfacl查看getfacl /path/to/parent如果输出里有mask或者额外的user:group:条目说明这个目录设了 ACL实际生效权限可能和ls -l看到的不一样。ACL 的 mask 会限制所有命名用户和命名组的最大权限这是个非常隐蔽的坑。4. 动手解决从临时绕过到彻底修复4.1 场景一自己的家目录下建不了文件夹这种情况通常是因为家目录权限被改坏了。正常家目录应该是drwx------或者drwxr-x---属主是你自己。如果某次误操作把属主改成了 root或者权限变成了dr-xr-xr-x没有写权限那你自己就建不了东西了。修复方法需要有 sudo 权限sudo chown -R $USER:$USER /home/$USER sudo chmod 755 /home/$USERchown -R会递归修改整个家目录的属主$USER是当前用户的环境变量。改完之后再试mkdir应该就正常了。这里要注意chmod 755会让同组和其他人能读你的家目录如果你在意隐私用chmod 700更安全。注意递归 chown 家目录之前先确认里面没有需要保留 root 属主的特殊文件比如某些服务生成的配置否则可能引发其他问题。稳妥做法是先ls -la看一眼有没有异常属主的文件。4.2 场景二共享目录里同组用户无法创建多人协作时最常见的需求一个项目目录组内所有人都能读写。标准做法是设置 SGID 位加上组写权限sudo mkdir -p /srv/shared sudo chown root:dev /srv/shared sudo chmod 2775 /srv/shared2775里的2就是 SGID 位。设置之后任何人在这个目录里新建的子目录和文件属组都会自动继承dev而不是创建者自己的主组。这样组内成员之间就不会出现我建的文件你改不了的问题。同时775保证了属主和属组都有读写执行权限。如果目录已经存在用chmod gs单独加 SGIDsudo chmod gs /srv/shared验证是否生效ls -ld /srv/shared # 应该看到 drwxrwsr-x属组位的 x 变成了 s4.3 场景三需要临时给某个用户开权限有时候不想大动干戈改组权限只想让某个特定用户能在一个目录里建东西这时候 ACL 是最合适的工具。比如让 bob 能在/srv/data里创建目录sudo setfacl -m u:bob:rwx /srv/data这条命令给 bob 单独授予了 rwx 权限不影响其他人。查看效果getfacl /srv/data # 会看到 user:bob:rwx 这一行如果要让 bob 新建的子目录也继承这个权限需要设置默认 ACLsudo setfacl -m d:u:bob:rwx /srv/datad:前缀表示 default ACL只对目录有效作用是让该目录下新建的文件和子目录自动带上这条 ACL。这个功能在需要精细控制权限的共享环境里非常实用比粗暴地改 777 优雅得多。4.4 场景四SELinux 导致的创建失败如果确认是 SELinux 在拦有两种处理思路。临时方案是设成 Permissive 模式但这只是排查手段不建议长期开着。彻底方案是给目录打上正确的 SELinux 上下文标签sudo semanage fcontext -a -t httpd_sys_rw_content_t /srv/webdata(/.*)? sudo restorecon -Rv /srv/webdata上面这个例子是把/srv/webdata及其子内容的上下文设成 Web 服务可读写的类型。具体用哪个类型取决于你的服务可以用ls -Z查看现有目录的上下文作为参考ls -Zd /var/www/html如果不想折腾 SELinux 策略也可以直接关闭 SELinux修改/etc/selinux/config把SELINUXenforcing改成disabled然后重启但这会降低系统安全性生产环境不推荐。我个人的建议是能打标签就打标签实在搞不定再考虑关闭。4.5 场景五挂载选项导致的只读如果findmnt显示文件系统是ro挂载的先尝试重新挂载为读写sudo mount -o remount,rw /path/to/mountpoint如果 remount 失败通常意味着底层存储出了问题需要检查dmesg里的磁盘错误信息。这种情况在云服务器上偶尔会遇到磁盘 I/O 异常后系统会自动把文件系统 remount 成只读以保护数据。这时候改权限是没用的得先解决存储层面的问题。5. 常见问题速查与避坑经验5.1 高频问题对照表报错信息最可能原因快速验证命令解决方向Permission denied父目录无 w 或 x 权限ls -ld 父目录chmod/chown 或加 ACLPermission denied路径中间某级无 x 权限namei -l 完整路径逐级修复执行权限Permission deniedSELinux 拦截getenforceausearch打标签或调策略Read-only file system文件系统只读挂载findmnt -T 路径remount rw 或查磁盘No space left on device磁盘或 inode 满df -h/df -i清理空间Operation not permitted不可变属性lsattr 目录chattr -i去掉属性这个表基本覆盖了我遇到过的九成以上情况。实际排查时从上往下试通常两三步就能定位到根因。5.2 几个容易忽略的细节不可变属性immutable用chattr i给目录加上不可变属性后连 root 都不能在里面创建或删除文件报错是Operation not permitted而不是 Permission denied容易让人摸不着头脑。用lsattr -d 目录查看如果看到i标志用chattr -i去掉即可。粘滞位sticky bit/tmp目录权限是drwxrwxrwt最后那个t就是粘滞位。它的作用是即使目录对所有人可写用户也只能删除自己创建的文件不能删别人的。如果你在共享目录里发现能建但不能删别人的文件这是正常设计不是 bug。符号链接的权限符号链接本身的权限位永远是lrwxrwxrwx没有意义真正生效的是它指向的目标文件的权限。排查时不要被链接的权限位迷惑要用ls -lL看目标。NFS 挂载的 root squash如果目录在 NFS 上服务端可能配置了root_squash导致 root 用户通过 NFS 访问时被映射成匿名用户权限判定完全变样。这种情况需要在 NFS 服务端调整导出选项客户端改权限没用。5.3 我踩过的三个真实坑第一个坑是 umask 设错。有次在脚本里临时umask 077之后忘了改回来结果后续所有新建目录都是700同组同事完全访问不了排查了半天才发现是 umask 的锅。教训是改 umask 一定要在脚本结束时恢复或者用子 shell 包裹(umask 077; mkdir xxx)避免污染当前环境。第二个坑是 ACL mask。给某个用户加了 ACL 之后发现权限没生效getfacl一看 mask 是r-x把写权限给屏蔽了。ACL 的 mask 是所有命名用户和命名组权限的上限加完 ACL 之后一定要检查 mask 是否足够必要时用setfacl -m m::rwx调整。第三个坑是 SELinux 上下文在拷贝文件时丢失。用cp把文件拷到 Web 目录后上下文还是原来的user_home_t导致服务读不了。正确做法是用cp -Z或者拷完执行restorecon。这个坑在部署 Web 应用时特别常见记住跨目录拷贝后 restorecon能省很多事。5.4 权限设计的最佳实践从长期维护的角度我建议遵循几条原则。第一能用组权限解决的就别用 ACLACL 虽然灵活但可读性差新人接手容易懵。第二共享目录统一用 SGID 组写权限的模式配合合理的 umask比如 002让协作顺畅。第三永远不要图省事用chmod 777这是安全大忌正确做法是明确属主属组再给最小必要权限。第四生产环境的 SELinux 尽量保持 Enforcing遇到问题打标签而不是关服务。排查权限问题的核心思路其实就一句话沿着路径从根到目标逐级确认每一级都要有执行权限目标父目录要有写权限同时排除文件系统、SELinux、ACL 这些额外因素。把这套逻辑刻在脑子里以后遇到任何 Permission denied 都能快速定位不用再靠sudo硬扛了。
Linux普通用户mkdir权限不足排查指南：从权限模型到SELinux彻底解决
1. 权限不足这件事几乎每个 Linux 普通用户都踩过刚接手一台 Linux 服务器或者在自己虚拟机上折腾环境的时候很多人都会遇到一个非常典型的场景用普通账号登录想在自己的工作目录下建一个项目文件夹敲下mkdir myproject结果终端直接甩回来一句mkdir: cannot create directory myproject: Permission denied。这个报错信息看起来简单但背后牵扯的东西其实不少——目录权限位、属主属组、umask 默认掩码、父目录的执行权限、SELinux 策略、挂载选项甚至文件系统本身的只读状态任何一个环节出问题都会导致同样的报错。我这些年帮人排查这类问题没有一百次也有八十次发现一个规律大部分人第一反应是直接sudo mkdir建完再用chown改属主能用是能用但这属于绕过问题而不是解决问题。真正搞明白权限模型之后你会发现绝大多数情况下根本不需要提权普通用户完全可以在自己该有权限的地方正常创建目录。这篇内容就是把我自己踩过的坑、总结出来的排查路径和实操方法完整梳理一遍从最基础的权限位讲起一直到 SELinux、挂载参数这些容易被忽略的深层原因最后给出一套可以直接照着做的排查流程。不管你是刚接触 Linux 的新手还是已经用了几年但一直靠sudo硬扛的老用户只要你想彻底搞清楚为什么普通用户建不了文件夹以及怎么优雅地解决这篇内容都值得花时间看完。下面我会按照先理解模型、再定位问题、最后动手解决的顺序展开每一步都配上可以直接复制的命令和实际输出示例。2. 先把 Linux 目录权限模型彻底搞明白2.1 权限位到底控制的是什么Linux 的文件权限用rwx三个字符表示读、写、执行对应数字 4、2、1。对于目录来说这三个权限的含义和普通文件完全不一样这是很多人混淆的根源。目录的读权限r决定你能不能列出目录里的内容也就是ls能不能用写权限w决定你能不能在这个目录里创建、删除、重命名文件或子目录执行权限x决定你能不能进入这个目录cd以及访问目录内文件的元数据。关键点来了在目录里创建文件夹需要的是该目录的写权限和执行权限而不是目录本身的什么特殊属性。很多人以为我要建文件夹所以我要对新建的那个文件夹有权限这个理解是反的。你新建的文件夹属主默认就是你你当然有权限真正卡住你的是父目录有没有给你写和执行权限。举个例子假设/home/alice这个目录的权限是drwxr-xr-x属主是 alice属组是 alice。那么 alice 自己在这个目录下建文件夹完全没问题因为属主位是rwx。但如果换成 bob 登录bob 对/home/alice来说属于其他人other只有r-x权限没有写权限那 bob 执行mkdir /home/alice/test就会直接报 Permission denied。这就是最典型的权限不足场景。2.2 属主、属组和其他人的判定顺序Linux 判断一个用户对某个文件或目录有什么权限顺序是固定的先看这个用户是不是属主owner如果是就用属主权限位如果不是再看这个用户是不是属于该文件的属组group如果是就用属组权限位如果都不是才用其他人other权限位。这个顺序不能颠倒而且一旦匹配到某一级就停止不会叠加。这里有个特别容易踩的坑如果一个用户既是属主又在属组里系统只按属主权限算。还有一种情况用户属于多个附加组只要其中任何一个组匹配到文件的属组就按属组权限算。你可以用id命令查看当前用户的所有组id # 输出示例uid1001(bob) gid1001(bob) groups1001(bob),27(sudo),1002(dev)上面这个输出说明 bob 同时属于 bob、sudo、dev 三个组。如果某个目录的属组是 dev那 bob 就按属组权限位来判定。2.3 umask 如何影响新建目录的默认权限新建目录的默认权限不是凭空来的它由umask值决定。目录的基础权限是 777rwxrwxrwx减去 umask 值就是实际权限。大多数 Linux 发行版普通用户的默认 umask 是 022所以新建目录的权限是 777 - 022 755也就是drwxr-xr-x。root 用户的 umask 通常是 022 或 077。查看当前 umaskumask # 输出0022umask 是 022 意味着新建目录同组用户和其他人都只有读和执行权限没有写权限。这在多人协作场景下就会出问题你和同事在同一个组里你建的目录同事却没法往里写东西。解决办法要么改 umask比如设成 002要么用mkdir -m显式指定权限要么事后chmod gw。我个人的习惯是在共享项目目录里直接用mkdir -m 2775前面的 2 是设置 SGID 位保证新建的子目录自动继承父目录的属组这个后面会详细讲。2.4 父目录执行权限的连锁效应这是最隐蔽的一个坑。假设/data/project目录权限是drwxrwx---属主 alice属组 devbob 属于 dev 组。看起来 bob 应该有写权限对吧但如果/data这一级目录对 bob 没有执行权限bob 连/data/project都进不去更别说在里面建东西了。目录的执行权限x是通行证没有它路径上的任何一级都会把你挡住。你可以用namei命令一次性查看整条路径每一级的权限namei -l /data/project/subdir # 输出会列出 / /data /data/project /data/project/subdir 每一级的权限和属主这个命令在排查明明权限看着没问题却还是进不去的场景时特别好用强烈建议记住。我遇到过好几次用户说我把目录权限改成 777 了还是不行结果一namei发现是上层某一级目录没有x权限改下层根本没用。3. 定位问题一套可复用的排查路径3.1 第一步永远是看报错和当前身份遇到Permission denied先别急着改权限先确认两件事当前登录的是谁以及报错的具体路径是什么。很多人用sudo su切到 root 之后忘了切回来然后奇怪为什么普通用户操作不了其实当前就是 root问题根本不在权限。whoami # 确认当前用户 pwd # 确认当前所在目录 ls -ld /path/to/parent # 查看目标父目录的权限、属主、属组ls -ld这个组合很关键-d表示查看目录本身而不是目录内容-l是长格式。输出类似drwxr-xr-x 2 alice dev 4096 Jan 1 10:00 /path/to/parent从这一行就能读出属主是 alice、属组是 dev、权限是 755。3.2 第二步用 namei 检查整条路径前面提到的namei -l是排查路径权限的利器。它会从根目录开始逐级列出每一层的权限。如果中间任何一级对当前用户没有x权限问题就定位到了。实际输出大概长这样f: /data/project/subdir drwxr-xr-x root root / drwxr-xr-x root root data drwxrwx--- alice dev project drwxr-xr-x alice dev subdir从这份输出能一眼看出/data/project这一级对 other 没有权限如果当前用户既不是 alice 也不在 dev 组里那就会被挡在project这一层。3.3 第三步确认文件系统是否可写有时候权限位看着完全正常但文件系统本身是只读挂载的这种情况在容器环境、救援模式、或者磁盘出问题后自动 remount 成只读的场景下很常见。用mount或者findmnt查看挂载选项findmnt -T /path/to/parent # 输出会显示该路径所在的文件系统及挂载参数如果输出里能看到roread-only那不管你怎么改权限都没用得先解决挂载问题。另外磁盘满了df -h显示 100%也会导致创建失败但报错通常是No space left on device而不是 Permission denied不过有些文件系统在 inode 耗尽时也会报奇怪的错误顺手df -i看一眼 inode 使用情况没坏处。3.4 第四步排查 SELinux 和 ACL如果前面几步都正常权限位没问题、路径通畅、文件系统可写但还是建不了目录那就要考虑 SELinux 和 ACL 了。SELinux 在 CentOS、RHEL、Fedora 上默认开启它会在传统权限之外再加一层强制访问控制。查看 SELinux 状态getenforce # 输出 Enforcing / Permissive / Disabled如果是 Enforcing可以临时设成 Permissive 测试一下问题是否消失sudo setenforce 0如果设成 Permissive 后能建目录了那基本可以确定是 SELinux 策略问题需要看审计日志ausearch -m avc -ts recent来定位具体是哪条策略在拦。ACL 则用getfacl查看getfacl /path/to/parent如果输出里有mask或者额外的user:group:条目说明这个目录设了 ACL实际生效权限可能和ls -l看到的不一样。ACL 的 mask 会限制所有命名用户和命名组的最大权限这是个非常隐蔽的坑。4. 动手解决从临时绕过到彻底修复4.1 场景一自己的家目录下建不了文件夹这种情况通常是因为家目录权限被改坏了。正常家目录应该是drwx------或者drwxr-x---属主是你自己。如果某次误操作把属主改成了 root或者权限变成了dr-xr-xr-x没有写权限那你自己就建不了东西了。修复方法需要有 sudo 权限sudo chown -R $USER:$USER /home/$USER sudo chmod 755 /home/$USERchown -R会递归修改整个家目录的属主$USER是当前用户的环境变量。改完之后再试mkdir应该就正常了。这里要注意chmod 755会让同组和其他人能读你的家目录如果你在意隐私用chmod 700更安全。注意递归 chown 家目录之前先确认里面没有需要保留 root 属主的特殊文件比如某些服务生成的配置否则可能引发其他问题。稳妥做法是先ls -la看一眼有没有异常属主的文件。4.2 场景二共享目录里同组用户无法创建多人协作时最常见的需求一个项目目录组内所有人都能读写。标准做法是设置 SGID 位加上组写权限sudo mkdir -p /srv/shared sudo chown root:dev /srv/shared sudo chmod 2775 /srv/shared2775里的2就是 SGID 位。设置之后任何人在这个目录里新建的子目录和文件属组都会自动继承dev而不是创建者自己的主组。这样组内成员之间就不会出现我建的文件你改不了的问题。同时775保证了属主和属组都有读写执行权限。如果目录已经存在用chmod gs单独加 SGIDsudo chmod gs /srv/shared验证是否生效ls -ld /srv/shared # 应该看到 drwxrwsr-x属组位的 x 变成了 s4.3 场景三需要临时给某个用户开权限有时候不想大动干戈改组权限只想让某个特定用户能在一个目录里建东西这时候 ACL 是最合适的工具。比如让 bob 能在/srv/data里创建目录sudo setfacl -m u:bob:rwx /srv/data这条命令给 bob 单独授予了 rwx 权限不影响其他人。查看效果getfacl /srv/data # 会看到 user:bob:rwx 这一行如果要让 bob 新建的子目录也继承这个权限需要设置默认 ACLsudo setfacl -m d:u:bob:rwx /srv/datad:前缀表示 default ACL只对目录有效作用是让该目录下新建的文件和子目录自动带上这条 ACL。这个功能在需要精细控制权限的共享环境里非常实用比粗暴地改 777 优雅得多。4.4 场景四SELinux 导致的创建失败如果确认是 SELinux 在拦有两种处理思路。临时方案是设成 Permissive 模式但这只是排查手段不建议长期开着。彻底方案是给目录打上正确的 SELinux 上下文标签sudo semanage fcontext -a -t httpd_sys_rw_content_t /srv/webdata(/.*)? sudo restorecon -Rv /srv/webdata上面这个例子是把/srv/webdata及其子内容的上下文设成 Web 服务可读写的类型。具体用哪个类型取决于你的服务可以用ls -Z查看现有目录的上下文作为参考ls -Zd /var/www/html如果不想折腾 SELinux 策略也可以直接关闭 SELinux修改/etc/selinux/config把SELINUXenforcing改成disabled然后重启但这会降低系统安全性生产环境不推荐。我个人的建议是能打标签就打标签实在搞不定再考虑关闭。4.5 场景五挂载选项导致的只读如果findmnt显示文件系统是ro挂载的先尝试重新挂载为读写sudo mount -o remount,rw /path/to/mountpoint如果 remount 失败通常意味着底层存储出了问题需要检查dmesg里的磁盘错误信息。这种情况在云服务器上偶尔会遇到磁盘 I/O 异常后系统会自动把文件系统 remount 成只读以保护数据。这时候改权限是没用的得先解决存储层面的问题。5. 常见问题速查与避坑经验5.1 高频问题对照表报错信息最可能原因快速验证命令解决方向Permission denied父目录无 w 或 x 权限ls -ld 父目录chmod/chown 或加 ACLPermission denied路径中间某级无 x 权限namei -l 完整路径逐级修复执行权限Permission deniedSELinux 拦截getenforceausearch打标签或调策略Read-only file system文件系统只读挂载findmnt -T 路径remount rw 或查磁盘No space left on device磁盘或 inode 满df -h/df -i清理空间Operation not permitted不可变属性lsattr 目录chattr -i去掉属性这个表基本覆盖了我遇到过的九成以上情况。实际排查时从上往下试通常两三步就能定位到根因。5.2 几个容易忽略的细节不可变属性immutable用chattr i给目录加上不可变属性后连 root 都不能在里面创建或删除文件报错是Operation not permitted而不是 Permission denied容易让人摸不着头脑。用lsattr -d 目录查看如果看到i标志用chattr -i去掉即可。粘滞位sticky bit/tmp目录权限是drwxrwxrwt最后那个t就是粘滞位。它的作用是即使目录对所有人可写用户也只能删除自己创建的文件不能删别人的。如果你在共享目录里发现能建但不能删别人的文件这是正常设计不是 bug。符号链接的权限符号链接本身的权限位永远是lrwxrwxrwx没有意义真正生效的是它指向的目标文件的权限。排查时不要被链接的权限位迷惑要用ls -lL看目标。NFS 挂载的 root squash如果目录在 NFS 上服务端可能配置了root_squash导致 root 用户通过 NFS 访问时被映射成匿名用户权限判定完全变样。这种情况需要在 NFS 服务端调整导出选项客户端改权限没用。5.3 我踩过的三个真实坑第一个坑是 umask 设错。有次在脚本里临时umask 077之后忘了改回来结果后续所有新建目录都是700同组同事完全访问不了排查了半天才发现是 umask 的锅。教训是改 umask 一定要在脚本结束时恢复或者用子 shell 包裹(umask 077; mkdir xxx)避免污染当前环境。第二个坑是 ACL mask。给某个用户加了 ACL 之后发现权限没生效getfacl一看 mask 是r-x把写权限给屏蔽了。ACL 的 mask 是所有命名用户和命名组权限的上限加完 ACL 之后一定要检查 mask 是否足够必要时用setfacl -m m::rwx调整。第三个坑是 SELinux 上下文在拷贝文件时丢失。用cp把文件拷到 Web 目录后上下文还是原来的user_home_t导致服务读不了。正确做法是用cp -Z或者拷完执行restorecon。这个坑在部署 Web 应用时特别常见记住跨目录拷贝后 restorecon能省很多事。5.4 权限设计的最佳实践从长期维护的角度我建议遵循几条原则。第一能用组权限解决的就别用 ACLACL 虽然灵活但可读性差新人接手容易懵。第二共享目录统一用 SGID 组写权限的模式配合合理的 umask比如 002让协作顺畅。第三永远不要图省事用chmod 777这是安全大忌正确做法是明确属主属组再给最小必要权限。第四生产环境的 SELinux 尽量保持 Enforcing遇到问题打标签而不是关服务。排查权限问题的核心思路其实就一句话沿着路径从根到目标逐级确认每一级都要有执行权限目标父目录要有写权限同时排除文件系统、SELinux、ACL 这些额外因素。把这套逻辑刻在脑子里以后遇到任何 Permission denied 都能快速定位不用再靠sudo硬扛了。
