apache/hadoop · error · UnsupportedOperationException

{} doesn't support getXAttr

Error message

{} doesn't support getXAttr

What it means

getXAttr(path, name) reads one extended attribute; AbstractFileSystem provides no base implementation, so filesystems without xattr support throw UnsupportedOperationException naming themselves. Only xattr-capable filesystems (HDFS with dfs.namenode.xattrs.enabled, POSIX-backed local filesystems) override it, and FileContext.getXAttr / 'hadoop fs -getfattr -n' hit the default elsewhere.

Source

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

      EnumSet<XAttrSetFlag> flag) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support setXAttr");
  }

  /**
   * Get an xattr for 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 get extended attribute
   * @param name xattr name.
   * @return byte[] xattr value.
   * @throws IOException raised on errors performing I/O.
   */
  public byte[] getXAttr(Path path, String name) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support getXAttr");
  }

  /**
   * Get all of the xattrs for a file or directory.
   * Only those xattrs for which the logged-in user has permissions to view
   * are returned.
   * <p>
   * Refer to the HDFS extended attributes user documentation for details.
   *
   * @param path Path to get extended attributes
   *
   * @return {@literal Map<String, byte[]>} describing the XAttrs of the file
   * or directory
   * @throws IOException raised on errors performing I/O.
   */
  public Map<String, byte[]> getXAttrs(Path path) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()

View on GitHub (pinned to 2add963021)

Solutions

  1. Probe fc.hasPathCapability(path, CommonPathCapabilities.FS_XATTRS) before reading
  2. Treat unsupported-xattr as 'no value': catch UnsupportedOperationException and apply the default, keeping HDFS behavior intact
  3. Keep xattr names in the user.* namespace; other namespaces may be rejected even on HDFS

Example fix

// before
byte[] v = fc.getXAttr(path, "user.lineage"); // -> UOE on s3a://

// after
byte[] v = null;
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_XATTRS)) {
  v = fc.getXAttr(path, "user.lineage");
} // else keep null default
Defensive patterns

Strategy: fallback

Validate before calling

if (fc.hasPathCapability(path, CommonPathCapabilities.FS_XATTRS)) {
  byte[] v = fc.getXAttr(path, name);
}

Type guard

boolean xattrCapable(Path p) throws IOException {
  return fc.hasPathCapability(p, CommonPathCapabilities.FS_XATTRS);
}

Try / catch

try { return fc.getXAttr(path, name); } catch (UnsupportedOperationException e) { return DEFAULT_VALUE; } // unsupported store == attribute absent

Prevention

When it happens

Trigger: fc.getXAttr(path, name) on S3A/ABFS/ftp/http stores; lookup of a tagging or lineage xattr on a defaultFS without xattr support; code that treats 'attribute missing' and 'xattrs unsupported' as the same case and only catches IOException.

Common situations: Metadata readers for frameworks that stamp user.* xattrs on HDFS, run in environments where some paths point at object stores; enrichment code that reads optional per-file hints; heterogeneous data lakes with mixed backends.

Related errors


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