apache/hadoop · error · UnsupportedOperationException
{getClass().getSimpleName()} doesn't support removeAclEntrie
Error message
{getClass().getSimpleName()} doesn't support removeAclEntries What it means
AbstractFileSystem.removeAclEntries is an opt-in ACL operation with no base implementation: it throws UnsupportedOperationException with the filesystem's simple class name unless the concrete AFS implements ACLs. Support exists only on HDFS (dfs.namenode.acls.enabled=true), RawLocalFileSystem where the OS has POSIX ACLs, and pass-through wrappers; FileContext delegates here, so 'hadoop fs -setfacl -x' fails the same way.
Source
Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/AbstractFileSystem.java:1289
* @throws IOException if an ACL could not be modified
*/
public void modifyAclEntries(Path path, List<AclEntry> aclSpec)
throws IOException {
throw new UnsupportedOperationException(getClass().getSimpleName()
+ " doesn't support modifyAclEntries");
}
/**
* Removes ACL entries from files and directories. Other ACL entries are
* retained.
*
* @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 permissionView on GitHub (pinned to 2add963021)
Solutions
- Gate on capability: fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS) before calling
- On HDFS confirm dfs.namenode.acls.enabled=true; the client cannot add ACL support to a store that lacks it
- Fall back to resetting permissions via setPermission when ACL removal is unsupported
Example fix
// before
fc.removeAclEntries(path, aclSpec); // -> UnsupportedOperationException
// after
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
fc.removeAclEntries(path, aclSpec);
} else {
fc.setPermission(path, fallbackPerms);
} Defensive patterns
Strategy: validation
Validate before calling
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
fc.removeAclEntries(path, aclSpec);
} Type guard
boolean aclCapable(Path p) throws IOException {
return fc.hasPathCapability(p, CommonPathCapabilities.FS_ACLS);
} Try / catch
try { fc.removeAclEntries(path, aclSpec); } catch (UnsupportedOperationException e) { /* no ACL support: nothing to remove, or reset with setPermission */ } Prevention
- Gate ACL pruning tooling on the fs.capability.paths.acls capability
- Skip ACL commands silently for object stores rather than failing the whole run
- Verify dfs.namenode.acls.enabled on HDFS before running setfacl-based scripts
When it happens
Trigger: fc.removeAclEntries(path, aclSpec) on S3A/ABFS/GCS, ftp, or http filesystems; scripts running setfacl -x against a defaultFS without ACL support; ACL cleanup code applied uniformly across mixed filesystems.
Common situations: Centralized permission-management tooling that prunes ACL entries on all stores; migrations from HDFS to object stores leaving ACL logic in place; containerized local tests on kernel filesystems lacking ACL mounts.
Related errors
- {getClass().getSimpleName()} doesn't support modifyAclEntrie
- {} doesn't support removeAcl
- {} doesn't support setAcl
- {getClass().getSimpleName()} doesn't support removeDefaultAc
- {} doesn't support getAclStatus
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/2c491bc0ae157a4c.
Report an issue: GitHub.