apache/hadoop · error · UnsupportedOperationException

{} doesn't support removeAclEntries

Error message

{} doesn't support removeAclEntries

What it means

FileSystem.removeAclEntries(Path, List<AclEntry>) is optional; the base class throws UnsupportedOperationException with getClass().getSimpleName() + " doesn't support removeAclEntries". Only HDFS-family clients (DistributedFileSystem, WebHdfsFileSystem, HttpFSFileSystem), ABFS and pass-through wrappers implement ACL mutation; local and typical object-store connectors throw.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java:3166

  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 describing entries to remove
   * @throws IOException if an ACL could not be modified
   * @throws UnsupportedOperationException if the operation is unsupported
   *         (default outcome).
   */
  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
   * @throws UnsupportedOperationException if the operation is unsupported
   *         (default outcome).
   */
  public void removeDefaultAcl(Path path)
      throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support removeDefaultAcl");
  }

  /**

View on GitHub (pinned to 2add963021)

Solutions

  1. Probe fs.hasPathCapability(path, CommonPathCapabilities.FS_ACLS) before revoking
  2. Target the HDFS path explicitly (hdfs://nameservice/...) instead of relying on fs.defaultFS
  3. Fall back to rewriting plain permission bits with setPermission on ACL-less stores
  4. Catch UnsupportedOperationException and log the store as bits-only so revocation drift is visible

Example fix

// before
fs.removeAclEntries(path, entriesToRemove); // throws on non-ACL stores

// after
if (fs.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fs.removeAclEntries(path, entriesToRemove);
} else {
  fs.setPermission(path, FsPermission.createImmutable((short) 0750));
}
Defensive patterns

Strategy: try-catch

Validate before calling

if (fs.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fs.removeAclEntries(path, entriesToRemove);
}

Type guard

static boolean supportsAclRemoval(FileSystem fs) {
  return fs instanceof DistributedFileSystem
      || fs instanceof WebHdfsFileSystem;
}

Try / catch

try {
  fs.removeAclEntries(path, entries);
} catch (UnsupportedOperationException e) {
  LOG.warn("{} is ACL-less; revoke via permission bits instead", fs.getUri());
}

Prevention

When it happens

Trigger: Calling fs.removeAclEntries(path, aclSpec) during permission revocation on a store that never overrode it: file://, s3a://, gs://, har://, or an unmodified custom FileSystem; cleanup code that strips specific user entries after offboarding.

Common situations: Offboarding/revocation automation run in the wrong environment (local tests instead of the HDFS cluster); datasets moved to object stores where the ACL playbook no longer applies.

Related errors

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