apache/hadoop · error · UnsupportedOperationException

getErasureCodeCodecs is not supported for HttpFs on {0}. Ple

Error message

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

What it means

HttpFS's GETECCODECS executor calls DistributedFileSystem.getAllErasureCodingCodecs(), an HDFS-only API. The executor runs against whatever FileSystem the HttpFS server's fs.defaultFS resolves to; if that instance is not a DistributedFileSystem (e.g. LocalFileSystem, WebHdfsFileSystem, S3AFileSystem), it throws UnsupportedOperationException, embedding the actual class name of {0} so you can see what backend was really used.

Source

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

  /**
   * Executor that performs a FSGetErasureCodingCodecs operation.
   */
  @InterfaceAudience.Private
  public static class FSGetErasureCodingCodecs
      implements FileSystemAccess.FileSystemExecutor<Map> {

    public FSGetErasureCodingCodecs() {
    }

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

  /**
   * 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;

View on GitHub (pinned to 2add963021)

Solutions

Set fs.defaultFS to the HDFS cluster (hdfs://namenode:8020) in the HttpFS server's configuration (its conf dir or httpfs-site.xml), then restart HttpFS.
Read the class name in the message ({0}) to identify which FileSystem was actually instantiated — e.g. 'WebHdfsFileSystem' means HttpFS is pointing at another HTTP endpoint, 'LocalFileSystem' means file:/// was used.
If the backend really is not HDFS, stop sending op=GETECCODECS through HttpFS and query erasure-coding codecs with the native client for that filesystem.

Example fix

<!-- before: HttpFS server core-site.xml -->
<property><name>fs.defaultFS</name><value>file:///</value></property>

<!-- after -->
<property><name>fs.defaultFS</name><value>hdfs://namenode.example.com:8020</value></property>

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("GETECCODECS requires HDFS; fs.defaultFS resolves to " + fs.getUri());
}

Type guard

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

Try / catch

try {
  Map codecs = httpFsClient.getErasureCodingCodecs();
} catch (UnsupportedOperationException e) {
  // message names the actual FileSystem class; fix server fs.defaultFS, not client code
  LOG.warn("HttpFS backend does not support EC codecs: {}", e.getMessage());
}

Prevention

Set fs.defaultFS explicitly to hdfs:// in the HttpFS server config; never rely on the file:/// default.
Add a startup smoke check (curl op=GETECCODECS) to deployment verification.
Avoid chaining HttpFS on top of WebHDFS when HDFS-only ops are needed.

When it happens

Trigger: An HTTP GET request to HttpFS/WebHDFS with op=GETECCODECS (e.g. GET http://host:14000/webhdfs/v1/?op=GETECCODECS&user.name=alice) when the HttpFS server's core-site fs.defaultFS is file:///, s3a://, adls://, or another WebHDFS/HttpFS URL (chained proxies). Any non-HDFS scheme produces this exact throw.

Common situations: fs.defaultFS left as the default file:/// in test or sandbox deployments; HttpFS fronting an object store instead of HDFS; HttpFS chained in front of WebHDFS (the client FileSystem becomes WebHdfsFileSystem, not DistributedFileSystem); HttpFS server's conf dir missing the HDFS core-site.xml so it falls back to local.

Related errors

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