apache/hadoop · error · UnsupportedOperationException

FileSystem ${item.fs.getUri()} does not support Erasure Codi

Error message

FileSystem ${item.fs.getUri()} does not support Erasure Coding

What it means

UnsupportedOperationException thrown by Ls.processPathArgument (Ls.java:236) when 'hadoop fs -ls -e' (display Erasure Coding policy) is used on a path whose ContentSummary reports a null erasure coding policy — i.e. the FileSystem does not support EC. Only HDFS reports EC policies (HDFS-EC, Hadoop 3.0+); local, viewfs, and object-store filesystems return null, and the shell refuses the listing rather than printing an empty policy column.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/shell/Ls.java:236

  @VisibleForTesting
  boolean isUseAtime() {
    return this.useAtime;
  }

  /**
   * Should EC policies be displayed.
   * @return true display EC policies, false doesn't display EC policies
   */
  @VisibleForTesting
  boolean isDisplayECPolicy() {
    return this.displayECPolicy;
  }

  @Override
  protected void processPathArgument(PathData item) throws IOException {
    if (isDisplayECPolicy() && item.fs.getContentSummary(item.path)
        .getErasureCodingPolicy() == null) {
      throw new UnsupportedOperationException("FileSystem "
          + item.fs.getUri() + " does not support Erasure Coding");
    }

    // implicitly recurse once for cmdline directories
    if (dirRecurse && item.stat.isDirectory()) {
      recursePath(item);
    } else {
      super.processPathArgument(item);
    }
  }

  @Override
  protected boolean isSorted() {
    // use the non-iterative method for listing because explicit sorting is
    // required based on time/size/reverse or Total number of entries
    // required to print summary first when non-recursive.
    return !isRecursive() || isOrderTime() || isOrderSize() || isOrderReverse();
  }

View on GitHub (pinned to 2add963021)

Solutions

Drop the -e flag for non-HDFS filesystems: plain 'hadoop fs -ls /path'
Query EC properly on HDFS with 'hdfs ec -getPolicy -path /path'
In code, catch UnsupportedOperationException and fall back to a normal listing without the EC column
Gate the flag by scheme: apply -e only when 'hdfs'.equals(item.fs.getUri().getScheme())

Example fix

# before
hadoop fs -ls -e file:///data/ec-dirs    # UnsupportedOperationException

# after
hadoop fs -ls file:///data/ec-dirs
# EC info only on HDFS:
hdfs ec -getPolicy -path /data/ec-dirs

Defensive patterns

Strategy: try-catch

Validate before calling

if (displayECPolicy
    && fs.getContentSummary(path).getErasureCodingPolicy() == null) {
  throw new UnsupportedOperationException(
      "FileSystem " + fs.getUri() + " does not support Erasure Coding");
}

Type guard

static boolean supportsErasureCodingPolicy(FileSystem fs) {
  // only HDFS reports an EC policy via ContentSummary
  return "hdfs".equals(fs.getUri().getScheme());
}

Try / catch

try {
  // listing with EC column
} catch (UnsupportedOperationException e) {
  // fall back to a plain listing without the EC policy column
}

Prevention

Gate -ls -e on the hdfs scheme; drop it for file://, viewfs:, object stores
Use 'hdfs ec -getPolicy -path' for authoritative EC status
Catch UnsupportedOperationException when reusing listing code across schemes

When it happens

Trigger: 'hadoop fs -ls -e file:///data' or 'hadoop fs -ls -e /mnt/viewfs-path' where the resolved FS is not HDFS; 'hdfs dfs -ls -e' against an HDFS 2.x-era cluster whose getContentSummary lacks EC; scripts reusing -e unconditionally across mixed-scheme paths.

Common situations: Admin scripts written on an EC-enabled HDFS 3 cluster reused against local paths or an older cluster; checking EC status of a path mounted via viewfs or har:; dashboards listing many URIs with one shared flag set.

Related errors

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