This is the documentation for Cloudera Enterprise 5.8.x. Documentation for other versions is available at Cloudera Documentation.

Troubleshooting HDFS Encryption

This topic contains HDFS Encryption-specific troubleshooting information in the form of issues you might face when encrypting HDFS files/directories and their workarounds.

Retrieval of encryption keys fails

Description

You see the following error when trying to list encryption keys 
user1@example-sles-4:~> hadoop key list
Cannot list keys for KeyProvider: KMSClientProvider[https: //example-sles-2.example.com:16000/kms/v1/]: Retrieval of all keys failed.

Solution

Make sure your truststore has been updated with the relevant certificate(s), such as the Key Trustee server certificate.

DistCp between unencrypted and encrypted locations fails

Description

By default, DistCp compares checksums provided by the filesystem to verify that data was successfully copied to the destination. However, when copying between unencrypted and encrypted locations, the filesystem checksums will not match since the underlying block data is different.

Solution

Specify the -skipcrccheck and -update distcp flags to avoid verifying checksums.

Cannot move encrypted files to trash

Description

With HDFS encryption enabled, you cannot move encrypted files or directories to the trash directory.

Solution

To remove encrypted files/directories, use the following command with the -skipTrash flag specified to bypass trash. 
rm -r -skipTrash /testdir

NameNode - KMS communication fails after long periods of inactivity

Description

Encrypted files and encryption zones cannot be created if a long period of time (by default, 20 hours) has passed since the last time the KMS and NameNode communicated.

Solution

  Important: Upgrading your cluster to the latest CDH 5 release will fix this problem. For instructions, see Upgrading from an Earlier CDH 5 Release to the Latest Release.
For lower CDH 5 releases, there are two possible workarounds to this issue :
  • You can increase the KMS authentication token validity period to a very high number. Since the default value is 10 hours, this bug will only be encountered after 20 hours of no communication between the NameNode and the KMS. Add the following property to the kms-site.xmlSafety Valve: 
    <property>
<name>hadoop.kms.authentication.token.validity</name> 
<value>SOME VERY HIGH NUMBER</value> 
</property>
  • You can switch the KMS signature secret provider to the string secret provider by adding the following property to the kms-site.xml Safety Valve: 
    <property>
<name>hadoop.kms.authentication.signature.secret</name> 
<value>SOME VERY SECRET STRING</value> 
</property>
Page generated July 8, 2016.