apache/hadoop · error · UnsupportedOperationException

removeAclEntries is only supported by storage accounts with

Error message

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

What it means

Thrown by AzureBlobFileSystem.removeAclEntries when the storage account lacks the hierarchical namespace (HNS). Removing individual ACL entries is only defined for HNS accounts with POSIX ACLs; flat-namespace accounts cannot honor it, so the driver fails fast client-side. Namespace state is cached after first resolution.

Source

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

  /**
   * Removes ACL entries from files and directories.  Other ACL entries are
   * retained.
   *
   * @param path    Path to modify
   * @param aclSpec List of AclEntry describing entries to remove
   * @throws IOException if an ACL could not be modified
   */
  @Override
  public void removeAclEntries(final Path path, final List<AclEntry> aclSpec)
      throws IOException {
    LOG.debug("AzureBlobFileSystem.removeAclEntries path: {}", path);
    TracingContext tracingContext = new TracingContext(clientCorrelationId,
        fileSystemId, FSOperationType.REMOVE_ACL_ENTRIES, true,
        tracingHeaderFormat, listener);

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

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

    Path qualifiedPath = makeQualified(path);

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

  /**

View on GitHub (pinned to 2add963021)

Solutions

Use an HNS-enabled storage account for ACL workflows.
Disable or gate ACL management features in the calling tool on flat accounts.
Catch UnsupportedOperationException and treat ACLs as unsupported for that mount.

Example fix

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

// after
try {
  fs.removeAclEntries(path, entries);
} catch (UnsupportedOperationException e) {
  LOG.warn("removeAclEntries 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.removeAclEntries(path, entries);
} catch (UnsupportedOperationException e) {
  LOG.debug("removeAclEntries unsupported on non-HNS account: {}", path);
}

Prevention

Run ACL tools only against HNS accounts.
Surface the account's namespace state in tool startup diagnostics.
Treat UnsupportedOperationException as a capability signal, not a failure to retry.

When it happens

Trigger: Calling fs.removeAclEntries(path, entries) against a non-HNS (flat namespace) storage account.

Common situations: Running ACL cleanup tooling (e.g., dfsadmin-style scripts, ranger policies) against a blob account without HNS; environment config pointing to an older account; migration from wasb:// where ACLs were silently unsupported.

Related errors

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