apache/hadoop · error · UnsupportedOperationException

{} doesn't support setAcl

Error message

{} doesn't support setAcl

What it means

setAcl (fully replace a file's ACL, discarding existing entries) is one of the ACL operations AbstractFileSystem deliberately leaves unimplemented: the default throws UnsupportedOperationException with the filesystem's simple class name. Only ACL-capable filesystems (HDFS with ACLs enabled, RawLocalFileSystem on POSIX-ACL kernels, wrapper filesystems) override it; FileContext.setAcl and 'hadoop fs -setfacl --set' hit the same default elsewhere.

Source

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

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

  /**
   * Gets the ACLs of files and directories.
   *
   * @param path Path to get
   * @return RemoteIterator{@literal <AclStatus>} which returns each AclStatus
   * @throws IOException if an ACL could not be read
   */
  public AclStatus getAclStatus(Path path) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support getAclStatus");
  }

  /**
   * Set an xattr of a file or directory.
   * The name must be prefixed with the namespace followed by ".". For example,

View on GitHub (pinned to 2add963021)

Solutions

1. Gate with fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS) and choose the permission path accordingly
2. On HDFS ensure dfs.namenode.acls.enabled=true; note the ACL spec must include user/group/other entries (the base permission bits)
3. Degrade to setPermission with equivalent mode bits when the store has no ACLs

Example fix

// before
fc.setAcl(path, fullAclSpec); // -> UnsupportedOperationException

// after
if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fc.setAcl(path, fullAclSpec);
} else {
  fc.setPermission(path, permsFromAcl(fullAclSpec));
}

if (fc.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fc.setAcl(path, fullAclSpec);
} else {
  fc.setPermission(path, permsFromAcl(fullAclSpec));
}

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

try { fc.setAcl(path, aclSpec); } catch (UnsupportedOperationException e) { /* fall back to setPermission with equivalent mode bits */ }

When it happens

Trigger: fc.setAcl(path, aclSpec) on S3A/ABFS/GCS, ftp, or http; 'hadoop fs -setfacl --set' against a defaultFS without ACL support; provisioning code that installs full ACLs on every output path regardless of store.

Common situations: Uniform access-control provisioning across mixed HDFS/object-store data lakes; tools ported from HDFS clusters to S3 endpoints; integration tests on LocalFs where the backing filesystem lacks ACL support.

Related errors

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