apache/hadoop · error · UnsupportedOperationException

{} doesn't support removeAcl

Error message

{} doesn't support removeAcl

What it means

removeAcl (discard all ACL entries except the base owner/group/other bits) has no default implementation in AbstractFileSystem: filesystems without ACL support throw UnsupportedOperationException naming themselves. It works only where ACLs exist (HDFS with dfs.namenode.acls.enabled=true, local filesystems with POSIX ACLs) and is reachable through FileContext and 'hadoop fs -setfacl -b'.

Source

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

   * @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");
  }

  /**
   * Fully replaces ACL of files and directories, discarding all existing
   * entries.
   *
   * @param path Path to modify
   * @param aclSpec List{@literal <AclEntry>} describing modifications, must
   * include entries for user, group, and others for compatibility with
   * permission bits.
   * @throws IOException if an ACL could not be modified
   */
  public void setAcl(Path path, List<AclEntry> aclSpec) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support setAcl");
  }

View on GitHub (pinned to 2add963021)

Solutions

1. Check fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS) before calling and skip otherwise
2. On HDFS, confirm dfs.namenode.acls.enabled=true in namenode config
3. When unsupported, apply setPermission to reset to plain bits instead of removeAcl

Example fix

// before
fc.removeAcl(path); // -> UnsupportedOperationException

// after
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fc.removeAcl(path);
} else {
  fc.setPermission(path, FsPermission.createImmutable((short) 0644));
}

if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fc.removeAcl(path);
} else {
  fc.setPermission(path, FsPermission.createImmutable((short) 0644));
}

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

try { fc.removeAcl(path); } catch (UnsupportedOperationException e) { /* no ACLs: reset mode bits with setPermission instead */ }

When it happens

Trigger: fc.removeAcl(path) on an object store, ftp, or http filesystem; setfacl -b executed against a defaultFS lacking ACLs; bulk permission-normalization jobs that clear ACLs on every path they visit.

Common situations: Data-lake migrations to S3-compatible storage keeping HDFS ACL cleanup steps; compliance scripts resetting access masks across heterogeneous stores; local tests on filesystems mounted without ACL support.

Related errors

• {getClass().getSimpleName()} doesn't support modifyAclEntrie
• {getClass().getSimpleName()} doesn't support removeAclEntrie
• {} 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/3899b2e6c39f6816. Report an issue: GitHub.