apache/hadoop · error · UnsupportedOperationException

removeAcl is only supported by storage accounts with the hie

Error message

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

What it means

Thrown by AzureBlobFileSystem.removeAcl when the storage account lacks hierarchical namespace. Removing all ACLs (reverting to base permission bits) is only meaningful on HNS accounts; flat accounts are rejected before any request is sent. The namespace state is resolved once and cached per filesystem instance.

Source

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

  }

  /**
   * Removes all but the base ACL entries of files and directories.  The entries
   * for user, group, and others are retained for compatibility with permission
   * bits.
   *
   * @param path Path to modify
   * @throws IOException if an ACL could not be removed
   */
  @Override
  public void removeAcl(final Path path) throws IOException {
    LOG.debug("AzureBlobFileSystem.removeAcl path: {}", path);
    TracingContext tracingContext = new TracingContext(clientCorrelationId,
        fileSystemId, FSOperationType.REMOVE_ACL, true, tracingHeaderFormat,
        listener);

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

    Path qualifiedPath = makeQualified(path);

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

  /**
   * Fully replaces ACL of files and directories, discarding all existing
   * entries.
   *
   * @param path    Path to modify

View on GitHub (pinned to 2add963021)

Solutions

Target an HNS-enabled storage account.
Skip or conditionalize the removeAcl step for flat accounts.
Catch UnsupportedOperationException and continue without ACL stripping.

Example fix

// before
fs.removeAcl(path);

// after
try {
  fs.removeAcl(path);
} catch (UnsupportedOperationException e) {
  LOG.warn("removeAcl 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.removeAcl(path);
} catch (UnsupportedOperationException e) {
  LOG.warn("removeAcl unsupported without HNS: {}", path);
}

Prevention

Verify the account has HNS before running ACL-reset jobs.
Prefer removeAcl over empty setAcl for clearing.
Keep HDFS-derived ACL scripts behind a filesystem-capability check.

When it happens

Trigger: Calling fs.removeAcl(path) against a non-HNS (flat namespace) ABFS account.

Common situations: Running setfacl -b / acl-reset tooling copied from HDFS workflows; jobs shared across mounts where one account is flat; emulators that do not implement HNS.

Related errors

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