apache/hadoop · error · UnsupportedOperationException

{} doesn't support getXAttrs

Error message

{} doesn't support getXAttrs

What it means

getXAttrs(path) fetches all extended attributes of a path; like every xattr method, the base AbstractFileSystem has no implementation and throws UnsupportedOperationException with the filesystem's simple class name. Filesystems that persist xattrs (HDFS with dfs.namenode.xattrs.enabled, POSIX-backed locals) override it; 'hadoop fs -getfattr -d' and FileContext.getXAttrs hit the default elsewhere.

Source

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

    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()
        + " doesn't support getXAttrs");
  }

  /**
   * 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
   * @param names XAttr names.
   * @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, List<String> names)
      throws IOException {

View on GitHub (pinned to 2add963021)

Solutions

  1. Gate the bulk read with fc.hasPathCapability(path, CommonPathCapabilities.FS_XATTRS)
  2. Skip xattr harvesting entirely for stores without the capability rather than failing the job
  3. On HDFS confirm dfs.namenode.xattrs.enabled and expect only visible namespaces (raw.* requires permissions)

Example fix

// before
Map<String, byte[]> all = fc.getXAttrs(path); // -> UOE

// after
Map<String, byte[]> all = fc.hasPathCapability(path,
        CommonPathCapabilities.FS_XATTRS)
    ? fc.getXAttrs(path)
    : Collections.emptyMap();
Defensive patterns

Strategy: validation

Validate before calling

Map<String, byte[]> all = fc.hasPathCapability(path,
        CommonPathCapabilities.FS_XATTRS)
    ? fc.getXAttrs(path)
    : Collections.emptyMap();

Type guard

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

Try / catch

try { return fc.getXAttrs(path); } catch (UnsupportedOperationException e) { return Collections.emptyMap(); }

Prevention

When it happens

Trigger: fc.getXAttrs(path) on an object store, ftp, or http filesystem; bulk metadata dumps iterating all files in mixed-protocol data lakes; getfattr -d executed against a defaultFS without xattr support.

Common situations: Audit/export tools that harvest every xattr from files; frameworks (tagging, encryption markers, lineage) whose readers run on environments backed by S3-compatible stores; local tests on kernel filesystems without user xattrs.

Related errors


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