apache/hadoop · error · UnsupportedOperationException

{getClass().getSimpleName()} doesn't support modifyAclEntrie

Error message

{getClass().getSimpleName()} doesn't support modifyAclEntries

What it means

The ACL API has no base implementation: AbstractFileSystem.modifyAclEntries throws UnsupportedOperationException naming the filesystem class unless the concrete AFS overrides it. Only HDFS (with dfs.namenode.acls.enabled=true) and RawLocalFileSystem (where the OS provides POSIX ACLs), plus pass-through wrappers, implement it; FileContext.modifyAclEntries (FileContext.java:2456) delegates here, so fc and 'hadoop fs -setfacl -m' fail identically on other stores.

Source

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

   */
  @InterfaceAudience.LimitedPrivate( { "HDFS", "MapReduce" })
  public List<Token<?>> getDelegationTokens(String renewer) throws IOException {
    return Collections.emptyList();
  }

  /**
   * Modifies ACL entries of files and directories.  This method can add new ACL
   * entries or modify the permissions on existing ACL entries.  All existing
   * ACL entries that are not specified in this call are retained without
   * changes.  (Modifications are merged into the current ACL.)
   *
   * @param path Path to modify
   * @param aclSpec List{@literal <AclEntry>} describing modifications
   * @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");
  }

  /**

View on GitHub (pinned to 2add963021)

Solutions

  1. Probe first: fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS) and skip or degrade when false
  2. On HDFS, ensure dfs.namenode.acls.enabled=true (ACLs need the NameNode flag and cannot be enabled client-side)
  3. Degrade to classic permission bits with setPermission when the store has no ACLs

Example fix

// before
fc.modifyAclEntries(path, aclSpec); // on s3a:// -> UnsupportedOperationException

// after
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fc.modifyAclEntries(path, aclSpec);
} else {
  fc.setPermission(path, FsPermission.createImmutable((short) 0750));
}
Defensive patterns

Strategy: validation

Validate before calling

if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fc.modifyAclEntries(path, aclSpec);
} else {
  fc.setPermission(path, fallbackPerms);
}

Type guard

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

Try / catch

try { fc.modifyAclEntries(path, aclSpec); } catch (UnsupportedOperationException e) { /* store has no ACLs: fall back to setPermission */ }

Prevention

When it happens

Trigger: fc.modifyAclEntries(path, aclSpec) on an object store (S3A, ABFS, GCS), ftp, or http filesystem; setfacl commands routed to a defaultFS that lacks ACL support; HDFS with dfs.namenode.acls.enabled=false failing the same call server-side.

Common situations: Security tooling that provisions ACLs uniformly across all configured filesystems; jobs moved from HDFS to S3-compatible storage; test environments on LocalFs running on filesystems (tmpfs, some containers) without POSIX ACL kernel support.

Related errors


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