apache/hadoop · error · UnsupportedOperationException

getTrashRoots is not supported for HttpFs on {0}. Please che

Error message

getTrashRoots is not supported for HttpFs on {0}. Please check your fs.defaultFS configuration

What it means

HttpFS's GETTRASHROOTS executor delegates to DistributedFileSystem.getTrashRoots(), which resolves per-user .Trash locations and exists only on HDFS. If the FileSystem that the server's fs.defaultFS resolves to is not a DistributedFileSystem, the executor throws UnsupportedOperationException with the concrete class name as {0}.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-httpfs/src/main/java/org/apache/hadoop/fs/http/server/FSOperations.java:2419

   * Executor that performs a FSGetTrashRoots operation.
   */
  @InterfaceAudience.Private
  public static class FSGetTrashRoots
      implements FileSystemAccess.FileSystemExecutor<Map> {
    final private boolean allUsers;

    public FSGetTrashRoots(boolean allUsers) {
      this.allUsers = allUsers;
    }

    @Override
    public Map execute(FileSystem fs) throws IOException {
      Map<String, Collection<FileStatus>> paths = new HashMap<>();
      if (fs instanceof DistributedFileSystem) {
        DistributedFileSystem dfs = (DistributedFileSystem) fs;
        paths.put("Paths", dfs.getTrashRoots(allUsers));
      } else {
        throw new UnsupportedOperationException("getTrashRoots is " +
            "not supported for HttpFs on " + fs.getClass() +
            ". Please check your fs.defaultFS configuration");
      }
      HttpFSServerWebApp.get().getMetrics().incrOpsTrashRoots();
      return paths;
    }
  }
}

View on GitHub (pinned to 2add963021)

Solutions

Set fs.defaultFS to hdfs://namenode:8020 in the HttpFS server's core configuration and restart HttpFS.
Check the class name in the message to see which FileSystem was instantiated; fix the scheme accordingly (file:/// -> LocalFileSystem, http(s):// -> WebHdfsFileSystem).
For non-HDFS backends, compute trash roots client-side (e.g. FileSystem.getTrashRoot) instead of using op=GETTRASHROOTS.

Example fix

// client: guard before calling
FileSystem fs = FileSystem.get(conf);
if (!(fs instanceof DistributedFileSystem)) {
  throw new IllegalStateException("GETTRASHROOTS requires an HDFS backend, got " + fs.getClass());
}
Collection<FileStatus> roots = ((DistributedFileSystem) fs).getTrashRoots(true);

Defensive patterns

Strategy: type-guard

Validate before calling

// server-side / embedder: verify backend before exposing the op
FileSystem fs = FileSystem.get(conf);
if (!(fs instanceof DistributedFileSystem)) {
  throw new IllegalStateException("GETTRASHROOTS requires HDFS; fs.defaultFS resolves to " + fs.getUri());
}

Type guard

static boolean supportsTrashRoots(FileSystem fs) {
  return fs instanceof DistributedFileSystem;
}

Try / catch

try {
  Map trash = httpFsClient.getTrashRoots(allUsers);
} catch (UnsupportedOperationException e) {
  LOG.warn("HttpFS backend does not support getTrashRoots: {}", e.getMessage());
  // fall back to per-user FileSystem#getTrashRoot on the client
}

Prevention

Pin fs.defaultFS to hdfs:// in the HttpFS conf dir and monitor for drift.
Smoke-test HDFS-only ops after any backend config change.
For non-HDFS backends use client-side trash root resolution instead of the REST op.

When it happens

Trigger: GET http://host:14000/webhdfs/v1/?op=GETTRASHROOTS&allusers=true (or allusers=false) against an HttpFS server whose fs.defaultFS is file:///, an object-store scheme, or another WebHDFS URL, so the created FileSystem is not DistributedFileSystem.

Common situations: Same family as other HDFS-only ops: default file:/// fs.defaultFS in dev setups, HttpFS placed in front of S3A/ABFS, HttpFS chained to WebHDFS, or the HDFS core-site.xml missing from the HttpFS configuration directory after an upgrade.

Related errors

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