apache/hadoop · error · UnsupportedOperationException

setAcl is only supported by storage accounts with the hierar

Error message

setAcl is only supported by storage accounts with the hierarchical namespace enabled.

What it means

Thrown by AzureBlobFileSystem.setAcl when the storage account does not have the hierarchical namespace enabled. Fully replacing an ACL is a POSIX-semantics operation available only on HNS accounts; the driver refuses up front on flat accounts. The check happens before the aclSpec validity check, so a non-HNS account fails with this even if the spec is also empty.

Source

Thrown at hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/AzureBlobFileSystem.java:1389

   * Fully replaces ACL of files and directories, discarding all existing
   * entries.
   *
   * @param path    Path to modify
   * @param aclSpec List of 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
   */
  @Override
  public void setAcl(final Path path, final List<AclEntry> aclSpec)
      throws IOException {
    LOG.debug("AzureBlobFileSystem.setAcl path: {}", path);
    TracingContext tracingContext = new TracingContext(clientCorrelationId,
        fileSystemId, FSOperationType.SET_ACL, true, tracingHeaderFormat,
        listener);

    if (!getIsNamespaceEnabled(tracingContext)) {
      throw new UnsupportedOperationException(
          "setAcl is only supported by storage accounts with the hierarchical "
              + "namespace enabled.");
    }

    if (aclSpec == null || aclSpec.size() == 0) {
      throw new IllegalArgumentException("The aclSpec argument is invalid.");
    }

    Path qualifiedPath = makeQualified(path);

    try {
      getAbfsStore().setAcl(qualifiedPath, aclSpec, tracingContext);
    } catch (AzureBlobFileSystemException ex) {
      checkException(path, ex);
    }
  }

  /**

View on GitHub (pinned to 2add963021)

Solutions

Enable/use a hierarchical-namespace storage account.
Disable ACL policy sync for mounts backed by flat accounts.
Degrade gracefully by catching UnsupportedOperationException.

Example fix

// before
fs.setAcl(path, entries);

// after
try {
  fs.setAcl(path, entries);
} catch (UnsupportedOperationException e) {
  LOG.warn("setAcl unsupported without hierarchical namespace: {}", path);
}

Defensive patterns

Strategy: try-catch

Validate before calling

static boolean isAclCapable(FileSystem fs) {
  try {
    fs.getAclStatus(new Path("/"));
    return true;
  } catch (UnsupportedOperationException e) {
    return false;
  } catch (IOException e) {
    return true;
  }
}

Try / catch

try {
  fs.setAcl(path, entries);
} catch (UnsupportedOperationException e) {
  LOG.warn("setAcl requires hierarchical namespace: {}", path);
}

Prevention

Target HNS accounts for ACL replacement workflows.
Disable Ranger/Hive ACL sync for flat mounts.
Cache the HNS probe result per filesystem instance.

When it happens

Trigger: Calling fs.setAcl(path, entries) against a non-HNS ABFS account, e.g., setfacl -s style replacement logic.

Common situations: ACL migration scripts replaying HDFS ACLs onto Azure; Ranger/Hive plugins syncing ACL policies; accounts created without HNS for cost or compatibility reasons.

Related errors

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