eclipse操作HDFS时异常的解决: Permission denied: user=administrator, access=WRITE,

缺乏、安全感 2023-06-24 01:20 10阅读 0赞

#      在虚拟机上搭建了一个Hadoop的环境（4节点），在用windows上的Java客户端来操作集群中的HDFS文件时出现了如下的认证错误 #

org.apache.hadoop.security.AccessControlException: Permission denied: user=Administrator, access=WRITE, inode="/input4":root:supergroup:drwxr-xr-x
    	at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
    	at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
    	at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
    	at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
    	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1698)
    	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1682)
    	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1665)
    	at org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
    	at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:3900)
    	at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:978)
    	at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:622)
    	at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
    	at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
    	at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
    	at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2049)
    	at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2045)
    	at java.security.AccessController.doPrivileged(Native Method)
    	at javax.security.auth.Subject.doAs(Subject.java:422)
    	at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
    	at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2043)
    
    	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    	at java.lang.reflect.Constructor.newInstance(Unknown Source)
    	at org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
    	at org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
    	at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:2589)
    	at org.apache.hadoop.hdfs.DFSClient.mkdirs(DFSClient.java:2558)
    	at org.apache.hadoop.hdfs.DistributedFileSystem$16.doCall(DistributedFileSystem.java:820)
    	at org.apache.hadoop.hdfs.DistributedFileSystem$16.doCall(DistributedFileSystem.java:816)
    	at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
    	at org.apache.hadoop.hdfs.DistributedFileSystem.mkdirsInternal(DistributedFileSystem.java:816)
    	at org.apache.hadoop.hdfs.DistributedFileSystem.mkdirs(DistributedFileSystem.java:809)
    	at org.apache.hadoop.fs.FileSystem.mkdirs(FileSystem.java:1815)
    	at com.yc.hdfs.HdfsDemo.mkdir(HdfsDemo.java:30)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    	at java.lang.reflect.Method.invoke(Unknown Source)
    	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
    	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
    Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException): Permission denied: user=Administrator, access=WRITE, inode="/input4":root:supergroup:drwxr-xr-x
    	at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
    	at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
    	at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
    	at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
    	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1698)
    	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1682)
    	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1665)
    	at org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
    	at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:3900)
    	at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:978)
    	at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:622)
    	at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
    	at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
    	at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
    	at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2049)
    	at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2045)
    	at java.security.AccessController.doPrivileged(Native Method)
    	at javax.security.auth.Subject.doAs(Subject.java:422)
    	at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
    	at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2043)
    
    	at org.apache.hadoop.ipc.Client.call(Client.java:1411)
    	at org.apache.hadoop.ipc.Client.call(Client.java:1364)
    	at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:206)
    	at com.sun.proxy.$Proxy12.mkdirs(Unknown Source)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    	at java.lang.reflect.Method.invoke(Unknown Source)
    	at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
    	at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
    	at com.sun.proxy.$Proxy12.mkdirs(Unknown Source)
    	at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.mkdirs(ClientNamenodeProtocolTranslatorPB.java:508)
    	at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:2587)
    	... 33 more

出现异常时的Java代码如下：

Configuration conf=new Configuration();
    FileSystem fs=FileSystem.get(conf);
    fs.mkdirs("/input4");

分析： 用户Administator在hadoop上执行写操作时被权限系统拒绝.

以下参考：   [https://blog.csdn.net/xiaoshunzi111/article/details/52062640 ][https_blog.csdn.net_xiaoshunzi111_article_details_52062640]

开始仔细的观察了这个错误的详细信息，看到user=Administrator, access=WRITE。这里的user其实是我当前系统（运行客户端的计算机的操作系统）的用户名，实际期望这里的user=root（root是我的HADOOP上面的用户名），但是它取的是当前的系统的用户名，很明显，如果我将当前系统的用户名改为hadoop，这个肯定也是可以行得通的，但是如果后期将开发的代码部署到服务器上之后，就不能方便的修改用户，此方法明显也不够方便。

现在就想着Configuration这个是一个配置类，有没有一个参数是可以在某个地方设置以哪个用户运行呢？搜索了半天，无果。没有找到相关的配置参数。

最终只有继续分析代码， FileSystem fs = FileSystem.get(URI.create(dest), conf);代码是在此处开始对HDFS进行调用，所以就想着将HADOOP的源码下下来，debug整个调用过程，这个user=Administator是在什么时间赋予的值。理解了调用过程，还怕找不到解决问题的办法么？

跟踪代码进入 FileSystem.get-->CACHE.get（）-->Key key = new Key(uri, conf);到这里的时候发现key值里面已经有Administrator了，所以关键肯定是在new key的过程。继续跟踪UserGroupInformation.getCurrentUser()-->getLoginUser()-->login.login()到这一步的时候发现用户名已经确定了，但是这个方法是Java的核心源码，是一个通用的安全认证，但对这一块不熟悉，但是debug时看到subject里面有NTUserPrincipal：Administator，所以就想着搜索一下这个东西是啥，结果就找到了下面这一篇关键的文章：

http://www.udpwork.com/item/7047.html

在此篇文章里面作者分析了hadoop的整个登录过程，对于我有用的是其中的这一段：

2.login.login();  
    这个会调用HadoopLoginModule的login()和commit()方法。  
    HadoopLoginModule的login()方法是一个空函数，只打印了一行调试日志 LOG.debug("hadoop login");  
    commit()方法负责把Principal添加到Subject中。  
    此时一个首要问题是username是什么？  
    在使用了kerberos的情况下，从javax.security.auth.kerberos.KerberosPrincipal的实例获取username。  
    在未使用kerberos的情况下，优先读取HADOOP\_USER\_NAME这个系统环境变量，如果不为空，那么拿它作username。否则，读取HADOOP\_USER\_NAME这个java环境变量。否则，从com.sun.security.auth.NTUserPrincipal或者com.sun.security.auth.UnixPrincipal的实例获取username。  
    如果以上尝试都失败，那么抛出异常LoginException("Can’t find user name")。  
    最终拿username构造org.apache.hadoop.security.User的实例添加到Subject中。

看完这一段，我明白了执行login.login的时候调用了hadoop里面的HadoopLoginModule方法，而关键是在commit方法里面，在这里优先读取HADOOP\_USER\_NAME系统环境变量，然后是java环境变量，如果再没有就从NTUserPrincipal等里面取。关键代码为：

if (!isSecurityEnabled() && (user == null)) \{  
      String envUser = System.getenv(HADOOP\_USER\_NAME);  
      if (envUser == null) \{  
        envUser = System.getProperty(HADOOP\_USER\_NAME);  
      \}  
      user = envUser == null ? null : new User(envUser);  
    \}

OK，看到这里我的需求也就解决了，只要在系统的环境变量里面添加HADOOP\_USER\_NAME=hadoop（HDFS上的有权限的用户，具体看自己的情况），或者在当前JDK的变量参数里面添加HADOOP\_USER\_NAME这个Java变量即可。我的情况添加系统环境变量更方法。

如果是在Eclipse里面运行，修改完环境变量后，记得重启一下eclipse，不然可能不会生效。  
解决办法

最终，总结下来解决办法大概有三种：

1、在系统的环境变量或java JVM变量里面添加HADOOP\_USER\_NAME，这个值具体等于多少看自己的情况，以后会运行HADOOP上的Linux的用户名。（修改完重启eclipse，不然可能不生效）

2、将当前系统的帐号修改为hadoop

3、使用HDFS的命令行接口修改相应目录的权限，hadoop fs -chmod 777 /user,后面的/user是要上传文件的路径，不同的情况可能不一样，比如要上传的文件路径为hdfs://namenode/user/xxx.doc，则这样的修改可以，如果要上传的文件路径为hdfs://namenode/java/xxx.doc，则要修改的为hadoop fs -chmod 777 /java或者hadoop fs -chmod 777 /，java的那个需要先在HDFS里面建立Java目录，后面的这个是为根目录调整权限。

4、右击计算机-->管理--->用户和组-->admin。。。改为与Linux下集群主机名相同

=====================

我这里采用了第一种方案解决，直接在eclipse中配置了一个环境变量  HADOOP\_USER\_NAME=root，问题解决：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 2][]

[https_blog.csdn.net_xiaoshunzi111_article_details_52062640]: https://blog.csdn.net/xiaoshunzi111/article/details/52062640
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191220115416697.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191220115452924.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191220115533631.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk=,size_16,color_FFFFFF,t_70