Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: fs-encryption (HADOOP-10150 and HDFS-6134)
    • Fix Version/s: None
    • Component/s: security
    • Labels:
      None

      Description

      Currently, users that want to remove an encrypted directory using the FsShell remove commands need to skip the trash.

      If users try to remove an encrypted directory while Trash is enabled, they will see the following error:

      [hdfs@schu-enc2 ~]$ hdfs dfs -rm -r /user/hdfs/enc
      2014-07-29 13:47:28,799 INFO  [main] hdfs.DFSClient (DFSClient.java:<init>(604)) - Found KeyProvider: KeyProviderCryptoExtension: jceks://file@/home/hdfs/hadoop-data/test.jks
      2014-07-29 13:47:29,563 INFO  [main] fs.TrashPolicyDefault (TrashPolicyDefault.java:initialize(92)) - Namenode trash configuration: Deletion interval = 1440 minutes, Emptier interval = 0 minutes.
      rm: Failed to move to trash: hdfs://schu-enc2.vpc.com:8020/user/hdfs/enc. Consider using -skipTrash option
      

      This is because the encrypted dir cannot be moved from an encryption zone, as the NN log explains:

      2014-07-29 13:47:29,596 INFO  [IPC Server handler 8 on 8020] ipc.Server (Server.java:run(2120)) - IPC Server handler 8 on 8020, call org.apache.hadoop.hdfs.protocol.ClientProtocol.rename from 172.25.3.153:48295 Call#9 Retry#0
      java.io.IOException: /user/hdfs/enc can't be moved from an encryption zone.
      	at org.apache.hadoop.hdfs.server.namenode.EncryptionZoneManager.checkMoveValidity(EncryptionZoneManager.java:175)
      	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.unprotectedRenameTo(FSDirectory.java:526)
      	at org.apache.hadoop.hdfs.server.namenode.FSDirectory.renameTo(FSDirectory.java:440)
      	at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameToInternal(FSNamesystem.java:3593)
      	at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameToInt(FSNamesystem.java:3555)
      	at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:3522)
      	at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename(NameNodeRpcServer.java:727)
      	at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rename(ClientNamenodeProtocolServerSideTranslatorPB.java:542)
      	at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
      	at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:607)
      	at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:932)
      	at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2099)
      	at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2095)
      	at java.security.AccessController.doPrivileged(Native Method)
      	at javax.security.auth.Subject.doAs(Subject.java:415)
      	at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1626)
      	at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2093)
      

        Issue Links

          Activity

          Hide
          Andrew Wang added a comment -

          Since having a per-EZ trash directory isn't really workable, I think the best thing to do is improve the log message to talk about encryption zones. Alejandro Abdelnur does this sound reasonable to you?

          Show
          Andrew Wang added a comment - Since having a per-EZ trash directory isn't really workable, I think the best thing to do is improve the log message to talk about encryption zones. Alejandro Abdelnur does this sound reasonable to you?
          Hide
          Alejandro Abdelnur added a comment -

          are we failing the remove to trash with an error?

          Show
          Alejandro Abdelnur added a comment - are we failing the remove to trash with an error?
          Hide
          Andrew Wang added a comment -

          Yea, you can see the example Stephen put in the description:

          rm: Failed to move to trash: hdfs://schu-enc2.vpc.com:8020/user/hdfs/enc. Consider using -skipTrash option
          

          We could improve this message to mention encryption zones and rename restrictions. It seems reasonable to require users to specify -skipTrash, since we can't preserve the existing behavior.

          Show
          Andrew Wang added a comment - Yea, you can see the example Stephen put in the description: rm: Failed to move to trash: hdfs://schu-enc2.vpc.com:8020/user/hdfs/enc. Consider using -skipTrash option We could improve this message to mention encryption zones and rename restrictions. It seems reasonable to require users to specify -skipTrash, since we can't preserve the existing behavior.
          Hide
          Stephen Chu added a comment -

          I agree that improving the error message and requiring users to skip the trash is appropriate and reasonable.

          Attaching a sample patch that appends the cause to the "Failed to move to trash" error message. Tested it out and the output is now changed to the clearer

          rm: Failed to move to trash: hdfs://schu-enc2.vpc.com:8020/user/hdfs/enc: /user/hdfs/enc can't be moved from an encryption zone.
          

          This is the same issue as HDFS-6760 Deletion of directories with snapshots will not output reason for trash move failure.

          Show
          Stephen Chu added a comment - I agree that improving the error message and requiring users to skip the trash is appropriate and reasonable. Attaching a sample patch that appends the cause to the "Failed to move to trash" error message. Tested it out and the output is now changed to the clearer rm: Failed to move to trash: hdfs: //schu-enc2.vpc.com:8020/user/hdfs/enc: /user/hdfs/enc can't be moved from an encryption zone. This is the same issue as HDFS-6760 Deletion of directories with snapshots will not output reason for trash move failure.
          Hide
          Andrew Wang added a comment -

          Since Stephen's already got this posted to HDFS-6760, let's take further discussion there. We can close this one as dup when the original is resolved on trunk.

          Show
          Andrew Wang added a comment - Since Stephen's already got this posted to HDFS-6760 , let's take further discussion there. We can close this one as dup when the original is resolved on trunk.
          Hide
          Andrew Wang added a comment -

          Duping this to HADOOP-10902, same fix as for snapshots. Thanks for looking into this Stephen!

          Show
          Andrew Wang added a comment - Duping this to HADOOP-10902 , same fix as for snapshots. Thanks for looking into this Stephen!

            People

            • Assignee:
              Unassigned
              Reporter:
              Stephen Chu
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development