apache/hadoop · error · IOException

pathName + " can't be moved because encryption zone " + getF

Error message

pathName + " can't be moved because encryption zone " + getFullPathName(zoneId) + " is currently under re-encryption"

What it means

IOException from EncryptionZoneManager.checkMoveValidityForReencryption: a rename whose parent chains into a zone is blocked while that zone's re-encryption status exists and is not Completed (Submitted or Running). During re-encryption the NameNode tracks files by inode id inside the zone, and renames would desync that bookkeeping, so moves are rejected until the re-encryption finishes.

Source

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

      }
      checkMoveValidityForReencryption(srcIIP.getPath(),
          srcParentEZI.getINodeId());
    } else if (dstInEZ) {
      checkMoveValidityForReencryption(dstIIP.getPath(),
          dstParentEZI.getINodeId());
    }
  }

  private void checkMoveValidityForReencryption(final String pathName,
      final long zoneId) throws IOException {
    assert dir.hasReadLock();
    final ZoneReencryptionStatus zs = reencryptionStatus.getZoneStatus(zoneId);
    if (zs != null && zs.getState() != ZoneReencryptionStatus.State.Completed) {
      final StringBuilder sb = new StringBuilder(pathName);
      sb.append(" can't be moved because encryption zone ");
      sb.append(getFullPathName(zoneId));
      sb.append(" is currently under re-encryption");
      throw new IOException(sb.toString());
    }
  }

  /**
   * Create a new encryption zone.
   * <p>
   * Called while holding the FSDirectory lock.
   */
  XAttr createEncryptionZone(INodesInPath srcIIP, CipherSuite suite,
      CryptoProtocolVersion version, String keyName)
      throws IOException {
    assert dir.hasWriteLock();

    // Check if src is a valid path for new EZ creation
    if (srcIIP.getLastINode() == null) {
      throw new FileNotFoundException("cannot find " + srcIIP.getPath());
    }

View on GitHub (pinned to 2add963021)

Solutions

  1. Check state: hdfs crypto -listReencryptionStatus -- wait until the zone shows Completed, then retry the rename.
  2. If the move is urgent: hdfs crypto -reencryptZone -cancel -path <zone>, wait for the cancellation to settle (status cleared), do the rename, then re-submit -start later.
  3. For big zones, schedule re-encryption during windows when rename-heavy jobs are paused.

Example fix

# before: rename fails -- zone still under re-encryption
hdfs crypto -listReencryptionStatus          # zone: RUNNING
# after: wait for completion, or cancel then retry
hdfs crypto -reencryptZone -cancel -path /secure
hdfs dfs -mv /secure/a /secure/b             # succeeds once status is cleared
Defensive patterns

Strategy: validation

Validate before calling

hdfs crypto -listReencryptionStatus
# any zone whose Status is not Completed will reject renames under it;
# wait or cancel (-reencryptZone -cancel -path <zone>) before scheduling moves

Try / catch

try {
  fs.rename(src, dst);
} catch (RemoteException re) {
  IOException e = re.unwrapRemoteException(IOException.class);
  if (e.getMessage() != null && e.getMessage().contains("under re-encryption")) {
    // transient: poll hdfs crypto -listReencryptionStatus, retry the rename once Completed
  } else { throw e; }
}

Prevention

When it happens

Trigger: An admin runs hdfs crypto -reencryptZone -start -path <zone> (key rotation); while the ZoneReencryptionStatus is Submitted/Running, any rename() with src or dst under that zone throws this.

Common situations: Key rotation overlapping normal user jobs on a large zone (re-encryption can run for hours/days); a re-encryption submitted and forgotten; scheduled mass-maintenance renames colliding with the security calendar.

Related errors


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