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 permission

View on GitHub (pinned to 2add963021)

Solutions

  1. Gate on capability: fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS) before calling
  2. On HDFS confirm dfs.namenode.acls.enabled=true; the client cannot add ACL support to a store that lacks it
  3. 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

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


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