apache/hadoop · error · ExitUtil.ExitException
53
53
Error message
Wrong filesystem for URI " + fs.getUri() + " : " + fs.getClass().getName()
What it means
S3GuardTool commands resolve the target filesystem and bindFilesystem() unwraps FilterFileSystems; if the result is not an S3AFileSystem it exits with ExitUtil.ExitException code EXIT_SERVICE_UNAVAILABLE (53) and message 'Wrong filesystem for URI <uri> : <fs class>'. The s3guard CLI only operates on s3a:// destinations, so the invocation resolved a different filesystem implementation.
Source
Thrown at hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/s3guard/S3GuardTool.java:288
protected S3AFileSystem getFilesystem() {
return filesystem;
}
/**
* Sets the filesystem; it must be an S3A FS instance, or a FilterFS
* around an S3A Filesystem.
* @param bindingFS filesystem to bind to
* @return the bound FS.
* @throws ExitUtil.ExitException if the FS is not an S3 FS
*/
protected S3AFileSystem bindFilesystem(FileSystem bindingFS) {
FileSystem fs = bindingFS;
baseFS = bindingFS;
while (fs instanceof FilterFileSystem) {
fs = ((FilterFileSystem) fs).getRawFileSystem();
}
if (!(fs instanceof S3AFileSystem)) {
throw new ExitUtil.ExitException(EXIT_SERVICE_UNAVAILABLE,
WRONG_FILESYSTEM + "URI " + fs.getUri() + " : "
+ fs.getClass().getName());
}
filesystem = (S3AFileSystem) fs;
return filesystem;
}
/**
* Reset the store and filesystem bindings.
*/
protected void resetBindings() {
filesystem = null;
}
protected final CommandFormat getCommandFormat() {
return commandFormat;
}
View on GitHub (pinned to 2add963021)
Solutions
- Pass an explicit s3a:// URI: hadoop s3guard <cmd> s3a://bucket/path or -fs s3a://bucket.
- Replace s3n:// and s3:// schemes with s3a:// in scripts and configs.
- Check fs.defaultFS / the command's -fs argument to see which filesystem actually got bound.
- On Hadoop 3.4+, drop S3Guard tool usage entirely (feature removed) and remove the corresponding commands from runbooks.
Example fix
# before: default FS is hdfs:// -> exit code 53 hadoop s3guard destroyed -fs / # after: explicit S3A URI (and on 3.4+, remove s3guard usage) hadoop s3guard <command> s3a://my-bucket/
Defensive patterns
Strategy: validation
Validate before calling
Path p = new Path(args[0]);
if (!"s3a".equals(p.toUri().getScheme())) {
throw new IllegalArgumentException(
"S3GuardTool requires an s3a:// URI, got: " + p);
} Try / catch
try {
tool.run(args);
} catch (ExitUtil.ExitException e) {
if (e.getExitCode() == 53) { // EXIT_SERVICE_UNAVAILABLE
// rerun with an explicit s3a://bucket URI
} else { throw e; }
} Prevention
- Always pass explicit s3a://bucket/path URIs to S3A-only tools.
- Migrate scripts off s3n:// and s3:// schemes to s3a://.
- On Hadoop 3.4+ remove s3guard CLI usage entirely (feature removed).
When it happens
Trigger: Running 'hadoop s3guard <command>' without an explicit s3a:// URI so fs.defaultFS (e.g. hdfs:// or file:///) resolves the path; passing -fs file:/// or an s3n:// URL (which binds the legacy S3 filesystem, not S3A); using a filtered filesystem (e.g. through Router-based/ViewFS layers) whose raw FS is not S3A.
Common situations: Running the CLI on a node whose core-site.xml default FS is the local filesystem or HDFS; legacy scripts using s3n:// or s3:// buckets; embedded invocation of S3GuardTool from tooling that passes a generic FileSystem. On 3.4+ most s3guard commands are gone anyway since S3Guard was removed.
Related errors
- 42
- S3Guard is no longer needed/supported, yet %s is configured
- Filesystem is configured to use unknown S3Guard store " + cl
- <path> is missing
- Too many arguments
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/fe9bb0b89d484edf.
Report an issue: GitHub.