apache/hadoop · error · UnsupportedOperationException

{} doesn't support removeAcl

Error message

{} doesn't support removeAcl

What it means

FileSystem.removeAcl(Path) is optional; the base class throws UnsupportedOperationException with getClass().getSimpleName() + " doesn't support removeAcl". It strips a file back to base ACL entries (owner/group/other bits); implemented only by HDFS-family clients, ABFS, and pass-through wrappers. Local filesystem and S3A/GCS-style connectors inherit the throwing default.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java:3196

  public void removeDefaultAcl(Path path)
      throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support removeDefaultAcl");
  }

  /**
   * 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
   * @throws UnsupportedOperationException if the operation is unsupported
   *         (default outcome).
   */
  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 describing modifications, which must include entries
   *   for user, group, and others for compatibility with permission bits.
   * @throws IOException if an ACL could not be modified
   * @throws UnsupportedOperationException if the operation is unsupported
   *         (default outcome).
   */
  public void setAcl(Path path, List<AclEntry> aclSpec) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support setAcl");
  }

View on GitHub (pinned to 2add963021)

Solutions

  1. Probe fs.hasPathCapability(path, CommonPathCapabilities.FS_ACLS) before resetting
  2. As the fallback, call setPermission(path, stat.getPermission()) — applying the base bits is exactly what removeAcl achieves on ACL stores
  3. Restrict ACL-reset jobs to hdfs:// paths
  4. Catch UnsupportedOperationException and count it as a no-op success with a log line

Example fix

// before
fs.removeAcl(path); // throws on stores without ACL support

// after
if (fs.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fs.removeAcl(path);
} else {
  FileStatus st = fs.getFileStatus(path);
  fs.setPermission(path, st.getPermission()); // equivalent end state
}
Defensive patterns

Strategy: try-catch

Validate before calling

if (fs.hasPathCapability(path, CommonPathCapabilities.FS_ACLS)) {
  fs.removeAcl(path);
} else {
  FileStatus st = fs.getFileStatus(path);
  fs.setPermission(path, st.getPermission()); // reapply base bits
}

Type guard

static boolean supportsFullAclReset(FileSystem fs) {
  return fs instanceof DistributedFileSystem
      || fs instanceof WebHdfsFileSystem;
}

Try / catch

try {
  fs.removeAcl(path);
} catch (UnsupportedOperationException e) {
  // equivalent fallback: reapply the base permission bits
  fs.setPermission(path, fs.getFileStatus(path).getPermission());
}

Prevention

When it happens

Trigger: Calling fs.removeAcl(path) — typically 'reset to plain permissions' — on a non-supporting store; permission-normalization sweeps that iterate many paths across mixed schemes and hit one on file:// or s3a://.

Common situations: Bulk permission resets after audits; data prepared on HDFS then replicated to an object store where the reset step still runs.

Related errors

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