apache/hadoop · error · UnsupportedOperationException

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

Error message

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

What it means

FSOperations.FSSatisyStoragePolicy.execute() invokes SATISFYSTORAGEPOLICY through DistributedFileSystem.satisfyStoragePolicy(), which schedules block-level storage-policy changes and exists only in HDFS. On any other backing filesystem the executor throws UnsupportedOperationException (HTTP 400 with this text), indicating the HttpFS server's fs.defaultFS is not HDFS.

Source

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

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

    private Path path;

    public FSSatisyStoragePolicy(String path) {
      this.path = new Path(path);
    }

    @Override
    public Void execute(FileSystem fs) throws IOException {
      if (fs instanceof DistributedFileSystem) {
        DistributedFileSystem dfs = (DistributedFileSystem) fs;
        dfs.satisfyStoragePolicy(path);
      } else {
        throw new UnsupportedOperationException("satisfyStoragePolicy is "
            + "not supported for HttpFs on " + fs.getClass()
            + ". Please check your fs.defaultFS configuration");
      }
      return null;
    }
  }

  /**
   * Executor that performs a getFileBlockLocations operation.
   */

  @InterfaceAudience.Private
  @SuppressWarnings("rawtypes")
  public static class FSFileBlockLocations implements FileSystemAccess.FileSystemExecutor<Map> {
    final private Path path;
    final private long offsetValue;
    final private long lengthValue;

View on GitHub (pinned to 2add963021)

Solutions

  1. Set the HttpFS server's fs.defaultFS to the HDFS nameservice and restart
  2. Trigger policy satisfaction via WebHDFS or hdfs crypto/evm CLI directly on the cluster
  3. For non-HDFS stores, remove the satisfy step: policy enforcement there is store-native
  4. Confirm the response is this capability error, not a 403/404 on the path, before changing configs

Example fix

<!-- before: httpfs-site.xml -->
<property><name>fs.defaultFS</name><value>file:///</value></property>
<!-- after -->
<property><name>fs.defaultFS</name><value>hdfs://ns1</value></property>
<!-- restart HttpFS; SATISFYSTORAGEPOLICY then schedules block moves on HDFS -->
Defensive patterns

Strategy: try-catch

Type guard

static DistributedFileSystem asDfs(FileSystem fs) {
  return fs instanceof DistributedFileSystem ? (DistributedFileSystem) fs : null;
}

Try / catch

try {
  fs.satisfyStoragePolicy(path);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().contains("not supported for HttpFs")) {
    throw new UnsupportedFeatureException("satisfyStoragePolicy requires HDFS-backed HttpFS", e);
  }
  throw e;
}

Prevention

When it happens

Trigger: Client sends op=SATISFYSTORAGEPOLICY via webhdfs:// (e.g., after changing a dir to COLD/HOT policy) while HttpFS proxies to a non-HDFS filesystem.

Common situations: Storage-tiering automation pointed at an HttpFS gateway fronting object storage; standalone HttpFS test servers; fs.defaultFS lost during config refactors.

Related errors


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