权限问题：加入对应组后无法写入用户命名空间所属目录

咱们先拆解下你的问题核心：你在主机上创建了uid/gid都是100999的用户和组，把自己（主机uid1000）加入了这个组，给test目录设了775权限（组用户本来该有读写执行权限），但写入时还是提示权限拒绝。结合你提到的用户命名空间，我梳理了几个最可能的原因和对应的解决步骤：

1. SELinux 上下文限制（最常见的坑） #

你给出的目录详情里有个细节：drwxrwxr-x.末尾的.，这表明SELinux处于强制模式，而且这个目录的SELinux上下文大概率不允许你的用户进行写入操作——哪怕文件权限看起来没问题，SELinux也会拦着你。

先验证是不是这个问题： #

临时关掉SELinux强制模式试试：

sudo setenforce 0

然后再去写入test目录，如果能成功，那肯定就是SELinux的锅了。

解决办法： #

• 要是你压根用不上SELinux，可以永久关掉：编辑/etc/selinux/config文件，把SELINUX=enforcing改成SELINUX=disabled，重启系统后就生效了。
• 要是需要保留SELinux，就给目录设置合适的上下文。比如如果是个人使用的目录，用用户home目录的上下文：

sudo chcon -R -t user_home_dir_t /path/to/test

如果是给用户命名空间/容器用的目录，换成容器专用的上下文：

sudo chcon -R -t container_file_t /path/to/test

2. 用户命名空间的UID/GID映射搞混了 #

你说100999是你的用户命名空间ID，这里可能有点混淆：用户命名空间里的UID/GID是映射到主机系统的真实UID/GID的，不是直接用主机的ID。如果映射关系不对，哪怕你在主机上属于100999组，在命名空间里也认不出来这个权限。

先查映射关系： #

进入你的用户命名空间后，执行这俩命令：

cat /proc/self/uid_map
cat /proc/self/gid_map

看看命名空间内的UID 100999是不是映射到了主机的UID 100999，GID同理。要是没对应上，那权限肯定出问题。

解决办法： #

创建用户命名空间的时候，直接指定映射关系。比如用unshare命令：

unshare -U --map-root-user --uidmap 100999:100999:1 --gidmap 100999:100999:1 /bin/bash

这条命令会把命名空间内的UID 100999和主机的UID 100999绑定，GID也是一样的逻辑。

3. 目录所在的文件系统挂载有特殊限制 #

如果test目录所在的文件系统是用nosuid、nodev这类选项挂载的，在用户命名空间场景下可能会间接影响权限，导致写入被拒。

先查挂载属性： #

执行这条命令，看看挂载时有没有加限制选项：

mount | grep $(df -P /path/to/test | tail -1 | awk '{print $1}')

看看输出里有没有nosuid、nodev这类可能搞事情的选项。

解决办法： #

要是确实有这些限制，重新挂载文件系统去掉它们就行：

sudo mount -o remount,rw,suid /dev/your-device /mount-point

记得把/dev/your-device换成实际的设备名，/mount-point换成挂载点。

4. 组权限没及时生效（缓存问题） #

有时候你刚把用户加入新组，当前的Shell会话不会立刻加载新的组权限，得刷新一下才行。

解决办法： #

• 最简单的：退出当前Shell，重新登录一次。
• 不想退出的话，执行这条命令刷新组信息：

newgrp test

刷新完再试试写入操作。

内容的提问来源于stack exchange，提问作者ankh