apache/hadoop · error · IOException

AES256 is enabled but an encryption key was set in fs.s3a.en

Error message

AES256 is enabled but an encryption key was set in fs.s3a.encryption.key ({diagnostics})

What it means

The mirror image of the SSE-C error: fs.s3a.encryption.algorithm is SSE-S3 ('AES256', S3-managed keys) but fs.s3a.encryption.key is set. S3-managed encryption never takes a customer key, so S3A rejects the combination at filesystem initialization, embedding the password diagnostics of the stray key in the message.

Source

Thrown at hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/S3AUtils.java:1518

    // look up the encryption key
    String encryptionKey = getS3EncryptionKey(bucket, conf,
        encryptionMethod.requiresSecret());
    int encryptionKeyLen =
        StringUtils.isBlank(encryptionKey) ? 0 : encryptionKey.length();
    String diagnostics = passwordDiagnostics(encryptionKey, "key");
    String encryptionContext = S3AEncryption.getS3EncryptionContextBase64Encoded(bucket, conf,
        encryptionMethod.requiresSecret());
    switch (encryptionMethod) {
    case SSE_C:
      LOG.debug("Using SSE-C with {}", diagnostics);
      if (encryptionKeyLen == 0) {
        throw new IOException(SSE_C_NO_KEY_ERROR);
      }
      break;

    case SSE_S3:
      if (encryptionKeyLen != 0) {
        throw new IOException(SSE_S3_WITH_KEY_ERROR
            + " (" + diagnostics + ")");
      }
      break;

    case SSE_KMS:
      LOG.debug("Using SSE-KMS with {}",
          diagnostics);
      break;

    case CSE_KMS:
      LOG.debug("Using CSE-KMS with {}",
          diagnostics);
      break;

    case DSSE_KMS:
      LOG.debug("Using DSSE-KMS with {}",
          diagnostics);
      break;

View on GitHub (pinned to 2add963021)

Solutions

  1. Remove fs.s3a.encryption.key (and fs.s3a.bucket.<bucket>.encryption.key) when using SSE-S3/AES256
  2. If customer-provided keys were intended, set fs.s3a.encryption.algorithm=SSE-C instead
  3. Scan configs and credential stores for stray encryption.key entries after encryption migrations
  4. Redeploy and verify with a small read/write against the bucket

Example fix

<!-- before: S3-managed encryption plus a stray customer key -->
<property><name>fs.s3a.encryption.algorithm</name><value>AES256</value></property>
<property><name>fs.s3a.encryption.key</name><value>some-key</value></property>

<!-- after: AES256 takes no customer key -->
<property><name>fs.s3a.encryption.algorithm</name><value>AES256</value></property>
Defensive patterns

Strategy: validation

Validate before calling

String alg = conf.getTrimmed("fs.s3a.encryption.algorithm", "");
char[] key = conf.getPassword("fs.s3a.encryption.key");
boolean keyPresent = key != null && !new String(key).trim().isEmpty();
if (("AES256".equalsIgnoreCase(alg) || "SSE-S3".equalsIgnoreCase(alg)) && keyPresent) {
  throw new IOException("fs.s3a.encryption.key must be unset for SSE-S3/AES256");
}

Try / catch

catch IOException containing 'AES256 is enabled but an encryption key was set' at fs init; remove the stray key - not retryable

Prevention

When it happens

Trigger: Switching a bucket from SSE-C/SSE-KMS to AES256 while leaving fs.s3a.encryption.key in place; global templates that always define the key; per-bucket encryption.key overrides leaking into a bucket configured for SSE-S3.

Common situations: Changing encryption strategy between environments (test on SSE-S3, prod on SSE-C) while copying properties; keys left behind after a migration; bucket-scoped overrides applied more widely than intended.

Related errors


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