apache/hadoop · error · UnsupportedOperationException

{} doesn't support setXAttr

Error message

{} doesn't support setXAttr

What it means

setXAttr is an opt-in extended-attribute operation: the base AbstractFileSystem throws UnsupportedOperationException with the filesystem's simple class name, and only filesystems that persist xattrs override it (HDFS with dfs.namenode.xattrs.enabled, some local/POSIX-backed filesystems). FileContext.setXAttr and 'hadoop fs -setfattr -n' reach this default on stores without xattr support.

Source

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

        XAttrSetFlag.REPLACE));
  }

  /**
   * Set 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 modify
   * @param name xattr name.
   * @param value xattr value.
   * @param flag xattr set flag
   * @throws IOException raised on errors performing I/O.
   */
  public void setXAttr(Path path, String name, byte[] value,
      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");

View on GitHub (pinned to 2add963021)

Solutions

1. Probe fc.hasPathCapability(path, CommonPathCapabilities.FS_XATTRS) before writing xattrs
2. Store the metadata in an alternative carrier (sidecar file, manifest, object metadata) when the store lacks xattrs
3. On HDFS verify dfs.namenode.xattrs.enabled=true and use only permitted namespaces (user.*; raw./security./trusted. are restricted)

Example fix

// before
fc.setXAttr(path, "user.lineage", value, EnumSet.of(XAttrSetFlag.CREATE));

// after
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_XATTRS)) {
  fc.setXAttr(path, "user.lineage", value, EnumSet.of(XAttrSetFlag.CREATE));
} else {
  writeSidecarMetadata(path, value);
}

if (fc.hasPathCapability(path, CommonPathCapabilities.FS_XATTRS)) {
  fc.setXAttr(path, name, value, EnumSet.of(XAttrSetFlag.CREATE));
} else {
  writeSidecarMetadata(path, value);
}

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

try { fc.setXAttr(path, name, value, flag); } catch (UnsupportedOperationException e) { /* persist metadata via sidecar file / object metadata instead */ }

When it happens

Trigger: fc.setXAttr(path, name, value, flag) on an object store, ftp, or http filesystem; frameworks stamping metadata (tagging, lineage markers) via xattrs uniformly across all configured stores; 'hadoop fs -setfattr' against a defaultFS without xattr support.

Common situations: Metadata tagging frameworks written for HDFS deployed onto S3-compatible storage; lineage/tracking tools that store job attributes as xattrs; tests running against LocalFs on filesystems without user xattr support.

Related errors

• {} doesn't support getXAttr
• {} doesn't support getXAttrs
• File system does not support symlinks
• {getClass().getSimpleName()} doesn't support modifyAclEntrie
• {getClass().getSimpleName()} doesn't support removeAclEntrie

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