apache/hadoop · error · IOException

"Could not find reencryption XAttr for file " + iip.getPath(

Error message

"Could not find reencryption XAttr for file " + iip.getPath()

What it means

Reencryption operations load the zone's raw CRYPTO_XATTR_ENCRYPTION_ZONE xattr via getZoneEncryptionInfoProto; when that xattr is absent the method throws IOException 'Could not find reencryption XAttr for file <path>'. Callers are the reencryption paths (updateReencryptionSubmitted from 'hdfs crypto -reencrypt -start/-cancel', progress updates from the reencryption thread, and completion handling), so in practice you see this when issuing a reencrypt command on a directory that is not an encryption zone root, or whose zone xattr was lost/corrupted.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSDirEncryptionZoneOp.java:369

            status.getNumReencryptionFailures(), Time.now(), null);

    final ZoneEncryptionInfoProto newZoneProto = PBHelperClient
        .convert(PBHelperClient.convert(zoneProto.getSuite()),
            PBHelperClient.convert(zoneProto.getCryptoProtocolVersion()),
            zoneProto.getKeyName(), newRiProto);

    final XAttr xattr = XAttrHelper
        .buildXAttr(CRYPTO_XATTR_ENCRYPTION_ZONE, newZoneProto.toByteArray());
    return xattr;
  }

  private static ZoneEncryptionInfoProto getZoneEncryptionInfoProto(
      final INodesInPath iip) throws IOException {
    final XAttr fileXAttr = FSDirXAttrOp.unprotectedGetXAttrByPrefixedName(
        iip.getLastINode(), iip.getPathSnapshotId(),
        CRYPTO_XATTR_ENCRYPTION_ZONE);
    if (fileXAttr == null) {
      throw new IOException(
          "Could not find reencryption XAttr for file " + iip.getPath());
    }
    try {
      return ZoneEncryptionInfoProto.parseFrom(fileXAttr.getValue());
    } catch (InvalidProtocolBufferException e) {
      throw new IOException(
          "Could not parse file encryption info for " + "inode " + iip
              .getPath(), e);
    }
  }

  /**
   * Save the batch's edeks to file xattrs.
   */
  static void saveFileXAttrsForBatch(FSDirectory fsd,
      List<FileEdekInfo> batch) {
    assert fsd.getFSNamesystem().hasWriteLock(RwLockMode.FS);
    if (batch != null && !batch.isEmpty()) {

View on GitHub (pinned to 2add963021)

Solutions

Run the reencrypt command against the encryption zone ROOT (the exact path shown by 'hdfs crypto -listZones'), not a subdirectory.
Verify the path is a zone root first: hdfs crypto -listZones, or HdfsAdmin.getEncryptionZoneForPath(path) and check ez.getPath().equals(path).
If the root really lost its zone xattr (deleted/recreated), recreate the zone (createEncryptionZone) before reencrypting.

Example fix

# before
hdfs crypto -reencrypt -start /secure/subdir  # subdir is not the zone root

# after
hdfs crypto -listZones   # shows zone root /secure
hdfs crypto -reencrypt -start /secure

Defensive patterns

Strategy: validation

Validate before calling

HdfsAdmin admin = new HdfsAdmin(fs.getUri(), conf);
EncryptionZone ez = admin.getEncryptionZoneForPath(path);
if (ez == null || !ez.getPath().equals(path)) {
  throw new IllegalArgumentException(
      path + " is not an encryption zone root; reencrypt the zone root "
      + (ez == null ? "(create the zone first)" : ez.getPath()));
}

Try / catch

catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().contains("Could not find reencryption XAttr")) {
    // resolve the actual zone root and retry against it
    EncryptionZone ez = admin.getEncryptionZoneForPath(path);
    if (ez != null) { reencryptStart(ez.getPath(), keyVersion); }
  } else { throw e; }
}

Prevention

Always resolve the zone root with getEncryptionZoneForPath and reencrypt exactly that path.
Automation should treat 'zone root changed' (delete + recreate) as a first-class failure mode and re-resolve.
Keep 'hdfs crypto -listZones' output in change-management tickets when scheduling reencryption.

When it happens

Trigger: 'hdfs crypto -reencrypt -start <dir>' where <dir> is not an EZ root (a plain directory, or a subdirectory inside a zone rather than the zone root itself); reencrypting a path whose zone xattr was removed; races where the zone is deleted while a reencrypt command is in flight.

Common situations: Operators pointing the reencrypt command at a subdirectory of the zone instead of the zone root; automation that assumes any path under an EZ accepts -reencrypt; a zone root that was deleted and recreated so the old path no longer carries the xattr.

Related errors

AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/9fd1760124d8e282. Report an issue: GitHub.