生产集群写入报错深入分析

业务反馈执行脚本报错如下

Exception in thread "main" org.apache.hadoop.security.AccessControlException: Permission denied: user=lf_xl_bp, access=WRITE, inode="/serv/smartsteps/raw/events/mobile_web_data/2019":hdfs:supergroup:drwxr-xr-x

登录接口机查看上层目录权限，未发现lf_xl_bp权限异常

接着深入查看权限，本次账期为7月账期。

发现下层目录实际权限为r-x

解决办法：

业务侧验证问题解决

总结：权限问题为常见问题，需要研究的点在于实际权限effective:r_x

衍生实验测试

通过hdfs命令为目录设置用户和组的default acl权限，在该目录下创建的子目录时用户和组的权限与设置的default acl权限不一致，提示“effective：r-x”

测试环境

1、redhat7.6

2、采用root操作

3、CM与CDH版本5.16.2

4、HDFS启用ACL权限管控

问题复现

1、使用cdhadmin用户创建一个hdfs目录

[root@cdh2 ~]# kinit cdhadmin

[root@cdh2 ~]# hadoop fs -mkdir /tmp/testacl

[root@cdh2 ~]# hadoop fs -getfacl /tmp/testacl

2、为huet用户和test组设置/tmp/testacl目录default acl权限为rwx

[root@cdh2 ~]# hadoop fs -setfacl -m default:user:huet:rwx /tmp/testacl

[root@cdh2 ~]# hadoop fs -setfacl -m default:group:test:rwx /tmp/testacl

[root@cdh2 ~]# hadoop fs -getfacl /tmp/testacl

通过user::rwx，group::r-x，other::r-x可以看到与umask-mode定义的022一致（即777 && 022=755，刚好对应user、group、other的权限）

3、在/tmp/testacl目录下创建一个子目录tt，并查看acl权限

[root@cdh2 ~]# hadoop fs -mkdir /tmp/testacl/tt

[root@cdh2 ~]# hadoop fs -getfacl /tmp/testacl/tt

通过上图可以看到父目录设置的huet用户和test组的default acl权限为rwx，但是新建的子目录权限显示为user:huet:rwx #effective:r-x用户和组的写权限丢失。

问题分析

HDFS服务dfs.umaskmode, fs.permissions.umask-mode默认配置为022

rwx权限说明：

r(read)可读权限，对应数字为4

w(write)可写权限，对应数字为2

x(execute)可执行权限，对应数字为1

HDFS文件或目录的权限位是由9个权限位来控制，每三位为一组，他们分别是文件属主（Owner）的读、写、执行，用户组（Group）的读、写、执行以及（Other）其它用户的读、写、执行。由于HDFS默认的umask为022，因此我们在HDFS上创建目录时目录的权限为755（即777 && 022 为 755），即test用户创建一个目录/tmp/test

1）owner对目录拥有rwx权限（7-0）

2）group对该目录只有r-x权限（7-2）

3）other user对该目录只有r-x权限（7-2）

因此这也就说明了为什么在我们为指定目录设置了default acl权限后，子目录会出现继承的权限与实际的设置的权限不一致问题，接下来主要介绍两种不同的方式修复问题。

问题解决

该问题在HDFS的JIRA中也有相应的记录具体链接如下：

https://issues.apache.org/jira/browse/HDFS-6962

4、方法一

通过指定HDFS的umask配置参数方式解决问题，该方式可以通过CM界面配置全局的，也可以在自己当前命令操作节点修改hdfs-site.xml配置文件来实现。

1.把默认值022改成000保存配置重启过时服务

删除创建的tt子目录在重新创建

[root@cdh2 ~]# hadoop fs -rmr /tmp/testacl/tt

[root@cdh2 ~]# hadoop fs -mkdir /tmp/testacl/tt

[root@cdh2 ~]# hadoop fs -getfacl /tmp/testacl/tt

注意：之前已创建的目录继承的ACL权限是不会因为修改配置而更新，需要重新创建该目录才可以。

方法二

根据JIRA里面描述HDFS提供了，给的解决方法是通过在hdfs-site.xml配置中将dfs.namenode.posix.inheritance.enabled设置为true，开启此配置后在指定了default acl时则umask不起作用。

在CM界面修改配置 hdfs-site.xml的NameNode高级配置代码段（安全阀）dfs.namenode.posix.acl.inheritance.enabled为true，点击保存

由于该配置为NameNode的高级配置，只需要重启NameNode服务即可

删除创建的tt子目录在重新创建

[root@cdh3 ~]# hadoop fs -rmr /tmp/testacl/tt

[root@cdh3 ~]# hadoop fs -mkdir /tmp/testacl/tt

[root@cdh3 ~]# hadoop fs -getfacl /tmp/testacl/tt

当然如果在赋权时加上-R选项就可以继承目录权限，但这样权限会被放大。