apache/hadoop · error · CredentialInitializationException
getCredentials failed: {e}
Error message
getCredentials failed: {e} What it means
CredentialInitializationException from AssumedRoleCredentialProvider.resolveCredentials(): the retrying call to the STS provider's resolveCredentials (AssumeRole) raised an IOException that is not an SdkClientException, so it is wrapped as 'getCredentials failed'. The credentials used with STS come from the inner chain fs.s3a.assumed.role.credentials.provider (default: SimpleAWSCredentialsProvider + EnvironmentVariableCredentialsProvider).
Source
Thrown at hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/auth/AssumedRoleCredentialProvider.java:187
/**
* Get credentials.
* @return the credentials
* @throws StsException if none could be obtained.
*/
@Override
@Retries.RetryRaw
public AwsCredentials resolveCredentials() {
try {
return invoker.retryUntranslated("resolveCredentials",
true,
stsProvider::resolveCredentials);
} catch (IOException e) {
// this is in the signature of retryUntranslated;
// its hard to see how this could be raised, but for
// completeness, it is wrapped as an Amazon Client Exception
// and rethrown.
throw new CredentialInitializationException(
"getCredentials failed: " + e,
e);
} catch (SdkClientException e) {
LOG.error("Failed to resolve credentials for role {}",
arn, e);
throw e;
}
}
/**
* Propagate the close() call to the inner stsProvider.
*/
@Override
public void close() {
S3AUtils.closeAutocloseables(LOG, stsProvider, credentialsToSTS, stsClient);
}
@OverrideView on GitHub (pinned to 2add963021)
Solutions
- Inspect the wrapped IOException - it carries the underlying STS failure detail
- Verify the inner chain resolves base credentials (simple/env providers by default) and its keys are valid
- Check network access to STS (sts.<region>.amazonaws.com): create a VPC endpoint or set fs.s3a.assumed.role.sts.endpoint and fs.s3a.assumed.role.sts.region
- Confirm the role's trust policy allows this principal and session options (name, duration, policy) are valid
Example fix
# before: locked-down VPC, no STS egress -> getCredentials failed <!-- after: point S3A at an STS VPC endpoint --> <property> <name>fs.s3a.assumed.role.sts.endpoint</name> <value>https://vpce-0abc.sts.eu-west-1.vpce.amazonaws.com</value> </property> <property> <name>fs.s3a.assumed.role.sts.region</name> <value>eu-west-1</value> </property>
Defensive patterns
Strategy: try-catch
Validate before calling
// Preflight STS reachability before jobs depend on assumed-role auth
new URL("https://sts." + region + ".amazonaws.com")
.openConnection().setConnectTimeout(3000); // throws on no route Try / catch
catch CredentialInitializationException with message 'getCredentials failed'; unwrap getCause() to get the STS detail - fix network/endpoint/inner-credentials rather than retrying (the provider already retried)
Prevention
- Preflight one S3 operation at job start to fail fast on auth setup
- Ensure STS reachability (VPC endpoint or egress) in locked-down networks
- Keep the inner provider chain's base credentials valid and refreshable
When it happens
Trigger: Assumed-role auth where the STS AssumeRole call keeps failing through retries: no route to the STS endpoint, a misconfigured fs.s3a.assumed.role.sts.endpoint/region, the inner provider chain erroring with an IOException, or invalid session parameters.
Common situations: VPC without internet egress or STS endpoint; custom STS endpoint typos or wrong region; role trust policy rejecting the caller; base credentials for the inner chain missing so STS cannot be signed; proxies blocking STS.
Related errors
- Session credentials in Hadoop configuration: No AWS Credenti
- Unset property fs.s3a.assumed.role.arn
- Class {className} AWS provider class cannot be used (configu
- End of stream reached draining data between ranges; expected
- HTTP stream closed before all bytes were read. Expected %,d
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/860558aa4e8e4949.
Report an issue: GitHub.