apache/hadoop · critical · IOException

"Could not parse file encryption info for inode " + iip.getP

Error message

"Could not parse file encryption info for inode " + iip.getPath()

What it means

While parsing the zone's encryption xattr, ZoneEncryptionInfoProto.parseFrom threw InvalidProtocolBufferException and it is rethrown as IOException 'Could not parse file encryption info for inode <path>'. The raw bytes stored in the CRYPTO_XATTR_ENCRYPTION_ZONE xattr are not a valid protobuf message — i.e. the zone's encryption metadata is corrupt. It affects reencryption/status updates, which read and rewrite this xattr.

Source

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

    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()) {
      for (FileEdekInfo entry : batch) {
        final INode inode = fsd.getInode(entry.getInodeId());
        // no dir lock, so inode could be removed. no-op if so.
        if (inode == null) {
          NameNode.LOG.info("Cannot find inode {}, skip saving xattr for"
              + " re-encryption", entry.getInodeId());

View on GitHub (pinned to 2add963021)

Solutions

Confirm all NameNodes (HA) and clients run one consistent Hadoop version; upgrade-path protobuf changes are a common cause.
Inspect the xattr bytes (hdfs getfattr -d xattr on the zone root, or an fsimage dump via oiv) to see whether the value is empty/truncated/text.
If the zone metadata is unrecoverable, plan a controlled repair: recreate the zone xattr via createEncryptionZone on the same path (after backing up image/edit logs) — accept that existing per-file EDEKs remain tied to the old key version.
Escalate to the Hadoop community (user@hadoop.apache.org) with the oiv output; hand-editing protobuf xattrs is a last resort.

Defensive patterns

Strategy: try-catch

Validate before calling

// defensive pre-check before scheduling reencryption: confirm the zone xattr parses
HdfsAdmin admin = new HdfsAdmin(fs.getUri(), conf);
EncryptionZone ez = admin.getEncryptionZoneForPath(path); // null/IO failure here already indicates bad zone metadata

Try / catch

catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("Could not parse file encryption info")) {
    // do not retry; isolate the zone, capture oiv/fsimage evidence, escalate to admins
    quarantineZoneAndEscalate(path, e);
  } else { throw e; }
}

Prevention

Never run mixed Hadoop versions across HA NameNodes; protobuf xattr schemas change between releases.
Never hand-edit raw.* xattrs with setfattr.
Back up fsimage/edits before encryption-zone maintenance so corrupt xattrs are recoverable.

When it happens

Trigger: Issuing reencrypt/status operations on a zone whose xattr bytes are malformed: xattr written or truncated by incompatible software, manual xattr edits (setfattr), bit rot on the fsimage/edit containing the xattr, or a downgrade to a Hadoop version with an incompatible ZoneEncryptionInfoProto schema.

Common situations: Downgrading or mixing Hadoop versions across an HA pair after zones were created; experiments that wrote the raw xattr manually; rare fsimage corruption after a disk issue. This is abnormal — a healthy cluster never produces this error.

Related errors

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