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
- Remove fs.s3a.encryption.key (and fs.s3a.bucket.<bucket>.encryption.key) when using SSE-S3/AES256
- If customer-provided keys were intended, set fs.s3a.encryption.algorithm=SSE-C instead
- Scan configs and credential stores for stray encryption.key entries after encryption migrations
- 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
- Model encryption algorithm and key as mutually exclusive options in templates
- After changing the encryption algorithm, grep configs and credential stores for leftover keys
- Apply per-bucket encryption overrides deliberately and review them
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
- SSE-C is enabled but no encryption key was declared in fs.s3
- Cannot find password option {key}
- Unable to create OutputStream with the given multipart uploa
- SimpleAWSCredentialsProvider: No AWS credentials in the Hado
- Failed to instantiate class {auditClassname} defined in {key
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/1a00ab8afd8072a9.
Report an issue: GitHub.