apache/hadoop · error · UnsupportedOperationException
{getClass().getSimpleName()} doesn't support removeDefaultAc
Error message
{getClass().getSimpleName()} doesn't support removeDefaultAcl What it means
removeDefaultAcl (strip the inherited 'default' ACL entries from a directory) is an opt-in ACL method: the base AbstractFileSystem throws UnsupportedOperationException with the filesystem's simple class name because default ACLs only exist where ACLs are implemented. HDFS with ACLs enabled and POSIX-ACL-capable local filesystems support it; object stores and most others never override the method.
Source
Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/AbstractFileSystem.java:1301
* @param path Path to modify
* @param aclSpec List{@literal <AclEntry>} describing entries to remove
* @throws IOException if an ACL could not be modified
*/
public void removeAclEntries(Path path, List<AclEntry> aclSpec)
throws IOException {
throw new UnsupportedOperationException(getClass().getSimpleName()
+ " doesn't support removeAclEntries");
}
/**
* Removes all default ACL entries from files and directories.
*
* @param path Path to modify
* @throws IOException if an ACL could not be modified
*/
public void removeDefaultAcl(Path path)
throws IOException {
throw new UnsupportedOperationException(getClass().getSimpleName()
+ " doesn't support removeDefaultAcl");
}
/**
* Removes all but the base ACL entries of files and directories. The entries
* for user, group, and others are retained for compatibility with permission
* bits.
*
* @param path Path to modify
* @throws IOException if an ACL could not be removed
*/
public void removeAcl(Path path)
throws IOException {
throw new UnsupportedOperationException(getClass().getSimpleName()
+ " doesn't support removeAcl");
}
/**View on GitHub (pinned to 2add963021)
Solutions
- Probe fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS) first and skip default-ACL cleanup when false
- On HDFS verify dfs.namenode.acls.enabled=true before issuing ACL commands
- Where unsupported, recreate the directory without defaults or fall back to plain setPermission
Example fix
// before
fc.removeDefaultAcl(path); // -> UnsupportedOperationException
// after
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
fc.removeDefaultAcl(path);
} Defensive patterns
Strategy: validation
Validate before calling
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
fc.removeDefaultAcl(path);
} Type guard
boolean aclCapable(Path p) throws IOException {
return fc.hasPathCapability(p, CommonPathCapabilities.FS_ACLS);
} Try / catch
try { fc.removeDefaultAcl(path); } catch (UnsupportedOperationException e) { /* default ACLs do not exist on this store: skip */ } Prevention
- Check the ACL capability before clearing default/inherited ACLs
- Make hardening scripts store-aware: HDFS gets ACL cleanup, object stores get permission bits
- On LocalFs verify the underlying filesystem is mounted with POSIX ACL support
When it happens
Trigger: fc.removeDefaultAcl(path) on a non-ACL filesystem (S3A, ABFS, http, ftp); 'hadoop fs -setfacl -k' routed to a defaultFS without ACL support; recursive permission-reset utilities that clear default ACLs on every directory.
Common situations: Hardening scripts that remove inheritance defaults across all data stores; pipelines moved from HDFS to object storage; test runs on LocalFs where the underlying kernel filesystem has no ACL support.
Related errors
- {getClass().getSimpleName()} doesn't support modifyAclEntrie
- {getClass().getSimpleName()} doesn't support removeAclEntrie
- {} doesn't support removeAcl
- {} doesn't support setAcl
- {} doesn't support getAclStatus
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/25ffaf8a3e8b3124.
Report an issue: GitHub.