在Linux系统里，当一个普通用户执行mkdir命令却收到“Permission denied”的提示时，往往意味着该用户在目标路径上不具备写权限，或者系统层面存在某些限制。这种问题在多人共用服务器、部署应用账户以及容器环境中十分常见，如果不搞清楚底层机制，很容易盲目使用root权限而导致安全隐患。
一、先确认权限与用户身份
遇到不能创建文件夹，第一步应当是查看目标目录本身的权限设置，以及当前用户到底属于哪些组。Linux的权限模型基于属主、属组和其他人三类身份，每一类都有读、写、执行三种权限。只有写权限（w）和执行权限（x）同时具备，用户才能在目录中创建子目录或文件。
我们可以使用如下命令来查看目录权限和用户信息：
# 查看目标目录的权限与属主属组 ls -ld /data/upload # 查看当前用户的uid和所属组 id # 假如用特定用户测试 id www-data
如果ls -ld显示类似“drwxr-xr-x 2 root root”的结果，说明属主是root，属组也是root，而其他人的权限只有r-x，没有w。此时非root且不在root组的用户自然无法创建文件夹。明确这一点，才能对症下药，而不是一味sudo。
二、通过修改权限或属组解决
最常规的修复方式有两种：一是给目录增加其他人的写权限，二是将用户加入目录属组并给属组写权限。第一种方法简单但安全性较差，任何用户都能写；第二种更规范，适合生产环境。
下面演示将目录属组改为devgroup，并赋予属组写权限，再把指定用户加入该组：
# 创建专用组（如已存在可忽略） groupadd devgroup # 修改目录属组 chown :devgroup /data/upload # 给属组添加写和执行权限 chmod 775 /data/upload # 将用户tom加入devgroup usermod -aG devgroup tom # 重新登录tom后验证 su - tom mkdir /data/upload/test
这种方案的优点是权限收敛，只有devgroup成员可写，降低了误删和越权风险。要注意usermod加组后，用户需重新登录会话才能生效，否则当前shell的组列表不会更新。若临时验证，可用newgrp devgroup切换。
三、排查只读挂载与inode耗尽
有时目录权限看起来完全正常，但依旧无法创建文件夹，这就涉及文件系统层面的问题。常见的是目录所在分区被以只读方式挂载，或者磁盘inode已经用完。
通过mount和df命令可以快速定位：
# 查看挂载选项，关注ro标识 mount | grep data # 查看inode使用情况 df -i /data # 若发现ro，可尝试重新挂载为读写（需root） mount -o remount,rw /data
如果df -i显示使用率100%，即便磁盘空间充足，也无法新建任何文件或目录。此时需要清理无用小文件，或重新规划文件系统。对于只读挂载，可能是系统检测到磁盘错误后自动保护了数据，应先排查硬件或文件系统错误再用remount解除。
四、SELinux与特殊属性的影响
在开启了SELinux的发行版（如CentOS、RHEL）中，即使常规权限正确，安全上下文不匹配也会拒绝写入。使用ls -Z能看到目录的安全上下文，必要时用semanage和restorecon调整。
另外，文件系统的特殊属性也会限制写入，例如用chattr设置了i属性的目录不可修改：
# 查看是否设置了不可修改属性 lsattr -d /data/upload # 若有i属性，移除后再试 chattr -i /data/upload
这类情况虽不常见，但在运维老服务器或模板机时容易踩坑。综合来看，从一个用户的身份、目录权限、挂载状态到安全模块逐层排查，就能稳定解决Linux中用户不能创建文件夹的问题，而不必每次都求助于root账户。