apache/hadoop · error · AccessControlException

Permission denied while accessing mount table {}: user {} do

Error message

Permission denied while accessing mount table {}: user {} does not have {} permissions.

What it means

When router permission checks (dfs.federation.router.permission.enable) are on, RouterPermissionChecker applies POSIX-style owner/group/other mode checks to mount-table entries. If the caller is neither the owner, nor in the entry's group, nor covered by the other-mode with an implying access, this AccessControlException reports the mount path, the user, and the missing access (READ/WRITE).

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-rbf/src/main/java/org/apache/hadoop/hdfs/server/federation/router/RouterPermissionChecker.java:94

    FsPermission mode = mountTable.getMode();
    if (getUser().equals(mountTable.getOwnerName())
        && mode.getUserAction().implies(access)) {
      return;
    }

    if (isMemberOfGroup(mountTable.getGroupName())
        && mode.getGroupAction().implies(access)) {
      return;
    }

    if (!getUser().equals(mountTable.getOwnerName())
        && !isMemberOfGroup(mountTable.getGroupName())
        && mode.getOtherAction().implies(access)) {
      return;
    }

    throw new AccessControlException(
        "Permission denied while accessing mount table "
            + mountTable.getSourcePath()
            + ": user " + getUser() + " does not have " + access.toString()
            + " permissions.");
  }

  /**
   * Check the superuser privileges of the current RPC caller. This method is
   * based on Datanode#checkSuperuserPrivilege().
   * @throws AccessControlException If the user is not authorized.
   */
  @Override
  public void checkSuperuserPrivilege() throws  AccessControlException {

    // Try to get the ugi in the RPC call.
    UserGroupInformation ugi = null;
    try {
      ugi = NameNode.getRemoteUser();

View on GitHub (pinned to 2add963021)

Solutions

1. Check the entry's owner/group/mode: hdfs dfsrouteradmin -listMountTable and fix ownership with hdfs dfsrouteradmin -update <path> -owner <user> -group <grp> -mode <mode> (run by the current owner or the router super user)
2. Run the admin operation as the router super user (the user running the Router) or a member of dfs.permissions.superusergroup
3. Grant the acting user the needed access via mode bits (e.g. 775 for group-write) instead of per-user exceptions

Example fix

# before: entry /data owned by teamA:teamA mode 755, teamB tries to update
hdfs dfsrouteradmin -update /data -ns ns1 -dst /data   # Permission denied
# after (as owner or super user)
hdfs dfsrouteradmin -update /data -owner teamA -group datadmins -mode 775

// Check mount entry permission before issuing the admin call (mirror of checker logic)
MountTable mt = mountTableStore.get(new PathScanner(path)); // or fetch matching entry
FsPermission mode = mt.getMode();
String user = UserGroupInformation.getCurrentUser().getShortUserName();
boolean allowed = user.equals(mt.getOwnerName()) && mode.getUserAction().implies(FsAction.WRITE)
    || userInGroup(mt.getGroupName()) && mode.getGroupAction().implies(FsAction.WRITE)
    || mode.getOtherAction().implies(FsAction.WRITE);
if (!allowed) throw new AccessControlException("skip RPC: no write on " + mt.getSourcePath());

try {
  client.getMountTableAdmin().updateMountTable(entry);
} catch (AccessControlException ace) {
  if (ace.getMessage() != null && ace.getMessage().startsWith("Permission denied while accessing mount table")) {
    // run as entry owner, join the entry group, or have the owner widen the mode
  }
  throw ace;
}

When it happens

Trigger: An admin RPC (RouterAdminServer: add/update/remove mount table, or any path checked via checkMountTable) issued by a user whose permissions on the target MountTable record do not imply the required FSAction - e.g. mode 755 entry and a non-owner attempting a write-type modification.

Common situations: Multiple teams sharing router admin duties with per-mount ownership; a mount entry created with restrictive owner:group:mode and later modified by another team; permission model enabled after mounts were created with defaults owned by a different user.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

• {} is not a super user
• Permission denied rename {}({}) to {}({}) Reason={}
• No mount point for %s
• Rename of {} to {} is not allowed, no eligible destination i
• Rename of {} to {} is not allowed. The remote location shoul

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