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

  1. Pass an explicit s3a:// URI: hadoop s3guard <cmd> s3a://bucket/path or -fs s3a://bucket.
  2. Replace s3n:// and s3:// schemes with s3a:// in scripts and configs.
  3. Check fs.defaultFS / the command's -fs argument to see which filesystem actually got bound.
  4. 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

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


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