eclipsar anomalías resueltos cuando se opera HDFS: Permiso denegado: user = administrador, acceso = WRITE,

     En la máquina virtual para construir un entorno de Hadoop (4-nodo), el siguiente error se produce cuando la autenticación de un cliente Java en las ventanas para operar el clúster del archivo 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

     código Java cuando se produce una excepción de la siguiente manera:

   

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

Análisis: Cuando el usuario se le deniega el permiso de operación del sistema Administator escritura se realiza en Hadoop.

 Las siguientes referencias:   https://blog.csdn.net/xiaoshunzi111/article/details/52062640

Esto comenzó a observar cuidadosamente los detalles del error, vea el usuario = Administrador, acceso = WRITE. usuario aquí es en realidad mi sistema actual (sistema operativo que ejecuta el equipo cliente) nombre de usuario, usuario real expectativa aquí = raíz (root es mi Hadoop por encima de nombre de usuario), pero se necesita es que los usuarios actuales del sistema nombre, obviamente, si iba a cambiar el actual sistema de nombres de usuario hadoop, esto puede ciertamente factible, pero luego si éste va a desarrollar el código desplegado en el servidor, no se puede modificar fácilmente el usuario, este método también es evidente no es lo suficientemente cómodo.

Ahora piensa de esta configuración es una clase de configuración, hay un argumento al que los usuarios pueden configurar para funcionar en un lugar determinado? Buscar durante mucho tiempo, pero en vano. no se encuentra parámetro de configuración correspondiente.

Última instancia, sólo seguir analizando el código, sistema de archivo fs = FileSystem.get (URI.create (dest), conf); código aquí para iniciar la llamada HDFS, así que creo que el siguiente código fuente abajo Hadoop, depurar todo el proceso de llamada, el usuario = tiempo administator lo que se da valor. Entendemos el proceso de llamada, miedo de no encontrar una solución al problema de qué?

El código de seguimiento en el FileSystem.get -> cache.get () -> Clave Clave = nueva clave (URI, conf); aquí se encontró valor de la clave que ha sido administrador, por lo que la clave debe estar en el proceso de duplicado de la llave . Continúa hacia UserGroupInformation.getCurrentUser () -> getLoginUser () -> login.login () para encontrar este punto del tiempo el nombre de usuario ha sido determinada, pero este método es el código fuente de Java central, es una certificación de seguridad común, pero éste no está familiarizado con, pero sujeto depuración de sierra que tiene NTUserPrincipal: administator, así que creo que esto es lo que los resultados de búsqueda para encontrar la clave para éste artículo siguiente:

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

En este artículo se analizan toda la hadoop dentro del proceso de inicio de sesión, que es útil para mí en este periodo:

    2.login.login ();
    esta llamará HadoopLoginModule el inicio de sesión () y commit () método.
    HadoopLoginModule el método de inicio de sesión () es una función vacía, sólo se imprime una línea de Log.DEBUG registro de depuración ( "Hadoop la sesión");
    el método commit () es responsable de añadir el director para el sujeto.
    En este momento, una cuestión principal es ¿cuál es el nombre de usuario?
    En el caso de utilizar Kerberos adquiere el nombre de usuario de ejemplo javax.security.auth.kerberos.KerberosPrincipal.
    En el caso de no utilizar Kerberos, lea HADOOP_USER_NAME esta prioridad las variables de entorno del sistema, si no está vacío, entonces lo tomo como un nombre de usuario. De lo contrario, lea HADOOP_USER_NAME la variable de entorno Java. De otro modo, obtener el usuario de la instancia de com.sun.security.auth.NTUserPrincipal o com.sun.security.auth.UnixPrincipal.
    Si no se logra, entonces tirado LoginException ( "No se puede encontrar el nombre de usuario ").
    La construcción final ejemplo toma nombre de usuario org.apache.hadoop.security.User añadió al sujeto.

Después de leer este pasaje, entiendo el momento de login.login ejecución denominado hadoop dentro de los métodos HadoopLoginModule, pero la clave es que se comprometan método en el interior, donde la prioridad son las variables de entorno del sistema HADOOP_USER_NAME de lectura, entonces la variable de entorno de Java, si no hay voluntad NTUserPrincipal tomada desde el interior por el estilo. El código clave es:

    si (isSecurityEnabled () && (usuario == null)) {
      Cadena envUser = System.getenv (HADOOP_USER_NAME);
      si (envUser == null) {
        envUser = System.getProperty (HADOOP_USER_NAME);
      }
      User = envUser == null? null: nuevo usuario (envUser);
    }

OK, ven aquí se resolverán mis necesidades, sólo tiene que añadir HADOOP_USER_NAME = hadoop en las variables de entorno del sistema en el interior (el usuario tiene permiso de HDFS, específicamente para ver su propia situación), o añadir HADOOP_USER_NAME en los parámetros actuales de las variables dentro del JDK la variable de Java. Mi situación es añadir más método de la variable de entorno del sistema.

Si está ejecutando dentro de Eclipse, después de modificar las variables de entorno, recuerde reiniciar el eclipse, de lo contrario podría no tener efecto.
soluciones

En última instancia, la solución probablemente concluirá en tres formas:

1, añadir una variable de entorno de sistema o variables de Java JVM dentro HADOOP_USER_NAME, este valor es igual al número de mirada específica a su propia situación, el futuro va a ejecutar en el nombre de usuario Hadoop Linux. (Terminado de modificar eclipse de reiniciar, de lo contrario, podría no tener efecto)

2, el sistema actual es modificado para tener en cuenta hadoop

3, el uso de permisos HDFS Command Line Interface para modificar el directorio apropiado, fs Hadoop -chmod 777 / usuario, espalda / usuario es el camino que desea cargar los archivos, diferentes situaciones pueden ser diferentes, como por ejemplo la ruta del archivo a subir a hdfs: / /namenode/user/xxx.doc, entonces tales modificaciones puede, si se desea cargar la ruta del archivo de hdfs: //namenode/java/xxx.doc, tendrá que modificar para fs Hadoop -chmod 777 / java o Hadoop fs - chmod 777 / java que es necesario crear el directorio de Java en HDFS el interior, detrás de esto es para ajustar los permisos para el directorio raíz.


4, haga clic en Equipo -> Administración ---> Usuarios y Grupos -> admin. . . Linux CLUSTERED reemplazado con el mismo nombre de host

 

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

Estoy aquí usando la primera solución para configurar una variable de entorno directamente en Eclipse HADOOP_USER_NAME = raíz, el problema se resuelve:

Publicados 107 artículos originales · ganado elogios 29 · vistas 180 000 +

Supongo que te gusta

Origin blog.csdn.net/zhangyingchengqi/article/details/103630097
Recomendado
Clasificación