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
- Gate the bulk read with fc.hasPathCapability(path, CommonPathCapabilities.FS_XATTRS)
- Skip xattr harvesting entirely for stores without the capability rather than failing the job
- 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
- Skip bulk xattr harvesting on stores that report no xattr capability
- Expect only user.* namespaces to be visible in bulk reads on HDFS
- Cache the per-store capability before iterating large listings
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
- {} doesn't support setXAttr
- {} doesn't support getXAttr
- 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/6c27b8db4fe1a058.
Report an issue: GitHub.