apache/hadoop · error · UnsupportedOperationException

{} doesn't support removeXAttr

Error message

{} doesn't support removeXAttr

What it means

AbstractFileSystem.removeXAttr(Path, String) is a default stub that unconditionally throws UnsupportedOperationException, prefixed with the concrete subclass name. Removing extended attributes is optional API surface; only filesystems that implement xattrs (HDFS, WebHDFS) override it. The error therefore reports that the filesystem mounted for the URI has no xattr support, not that the attribute is missing (that case throws NoXAttrSetException on HDFS instead).

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/AbstractFileSystem.java:1467

  public List<String> listXAttrs(Path path)
          throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
            + " doesn't support listXAttrs");
  }

  /**
   * Remove an xattr of a file or directory.
   * The name must be prefixed with the namespace followed by ".". For example,
   * "user.attr".
   * <p>
   * Refer to the HDFS extended attributes user documentation for details.
   *
   * @param path Path to remove extended attribute
   * @param name xattr name
   * @throws IOException raised on errors performing I/O.
   */
  public void removeXAttr(Path path, String name) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support removeXAttr");
  }

  /**
   * The specification of this method matches that of
   * {@link FileContext#createSnapshot(Path, String)}.
   *
   * @param path the path.
   * @param snapshotName snapshot name.
   * @throws IOException raised on errors performing I/O.
   * @return path.
   */
  public Path createSnapshot(final Path path, final String snapshotName)
      throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support createSnapshot");
  }

View on GitHub (pinned to 2add963021)

Solutions

  1. Check the class name in the message and the path's URI scheme; removeXAttr only works on hdfs:// and webhdfs://.
  2. Skip or gate cleanup logic by scheme so it only runs where xattrs exist.
  3. Catch UnsupportedOperationException and treat removal as a no-op when the feature is optional.
  4. Verify you actually have an xattr to remove: on HDFS a missing attribute is a different exception (NoXAttrSetException), so a UOE here always means unsupported scheme.

Example fix

// before
fc.removeXAttr(path, "user.lineage"); // throws on unsupported scheme

// after
try {
  fc.removeXAttr(path, "user.lineage");
} catch (UnsupportedOperationException e) {
  // no xattr support on this filesystem: nothing to remove
}
Defensive patterns

Strategy: try-catch

Validate before calling

static boolean supportsXAttrRemove(FileContext fc, Path probe) {
  try {
    fc.listXAttrs(probe);
    return true;
  } catch (UnsupportedOperationException e) {
    return false;
  }
}

Try / catch

try {
  fc.removeXAttr(path, name);
} catch (UnsupportedOperationException e) {
  // no xattr engine on this filesystem: nothing to remove
}

Prevention

When it happens

Trigger: Calling FileContext.removeXAttr(path, "user.foo") (or the equivalent shell path `hadoop fs -removexattr`) against s3a/gs/wasb/ftp schemes or a local backend without the override. Cleanup code that strips user.* attributes on job completion fails when the path is on an unsupported store.

Common situations: Jobs migrated from HDFS to object stores keep attribute-cleanup logic; config changes (fs.defaultFS, viewfs mount table) point cleanup paths at non-HDFS targets; tests run against local FS hit the stub.

Related errors

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