HDFS权限模型¶

理解HDFS权限模型的一个关键点。HDFS里显示的组，其实是一个存储在NameNode内存中的逻辑字符串，它并不要求这个组在Linux系统中真实存在。

就像你在HDFS文件列表里看到的“supergroup”，它只是一个标签。HDFS在判断权限时，会拿着这个标签和用户的组列表去比对，看是否匹配，而不会去问Linux系统“嘿，你有一个叫supergroup的组吗？”。

这就导致了你看到的“矛盾”：

观察点	看到的内容	原因
HDFS文件列表	组是 `supergroup`	HDFS文件或目录的属性中，所属组被设置为 `supergroup` 这个字符串。
Linux系统中	找不到 `supergroup` 组	Linux系统组列表（`/etc/group`）里，确实没有叫 `supergroup` 的组。

所以，现在问题的关键不是让Linux“承认”这个组，而是要让HDFS在检查权限时，能确认你的用户 dolphinscheduler 属于 supergroup 这个逻辑组。

这背后是HDFS的组映射机制在起作用。简单来说，当用户访问HDFS时，NameNode会通过一套机制（比如查询Linux的 groups 命令）来获取该用户所属的所有Linux组。然后，它会拿这个列表和文件/目录的所属组（比如 supergroup）进行比较。如果 supergroup 这个字符串出现在了用户的组列表中，权限检查就通过了。

你遇到的“Linux中无此组”的问题，通常和以下几个因素有关：

缓存机制：NameNode会缓存用户的组信息，默认缓存时间是300秒（5分钟）。即便你刚在Linux里把用户加到了 supergroup，NameNode可能还在用旧数据。
组映射配置：NameNode可能配置了其他的组映射服务（例如直接查询LDAP），而不是直接读取本地Linux的组信息。这样一来，Linux本地有没有这个组就不重要了，只要映射服务认为用户属于 supergroup 就行。
HDFS的继承逻辑：HDFS上新建文件或目录时，它的所属组默认会继承父目录的组，和当前用户的Linux主组没有直接关系。你之前看到的 /warehouse/gmall/ods/ods_log_inc 目录组为 supergroup，很可能就是这种情况。

如何验证和解决？¶

既然我们已经确认你的用户 dolphinscheduler 已被加入Linux的 supergroup 组（id dolphinscheduler 能查到），那问题基本就落在“缓存”或“映射”上。你可以按以下步骤操作：

刷新NameNode的组映射缓存（最推荐）：用 hdfs 超级用户执行以下命令，强制NameNode重新加载所有用户的组信息，这会立即生效。
```
sudo -u hdfs hdfs dfsadmin -refreshSuperUserGroupsConfiguration
```
耐心等待缓存过期：如果因为某些原因无法执行刷新命令，可以等待默认的缓存时间（300秒）过后再试。
验证权限：重新运行你的DolphinScheduler任务，或者在命令行模拟一下：
```
sudo -u dolphinscheduler hdfs dfs -mkdir /tmp/test_dolphinscheduler
```
如果这条命令能成功执行，就说明权限问题已经解决了。

总的来说，你看到的这个“矛盾”是完全正常的现象，并不影响HDFS的权限判断。最快捷的解决方法就是刷新一下NameNode的组映射缓存。如果刷新后问题依旧，那我们就需要再看看你的 core-site.xml 文件中关于组映射的配置项 hadoop.security.group.mapping 是否有特殊设置了。