apache/hadoop · error · AccessControlException

User {} cannot perform operation {} on {}

Error message

User {} cannot perform operation {} on {}

What it means

verifyAndGetJob throws AccessControlException when the job exists but job.checkAccess(ugi, accessType) fails for the current user. Access is granted to the job owner, queue admins and cluster admins, plus users listed in the job-level ACLs (mapreduce.job.acl-view-job / mapreduce.job.acl-modify-job, intersected with the cluster-wide mapreduce.cluster.acl-view-job / acl-modify-job settings).

Source

Thrown at hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/client/MRClientService.java:211

  class MRClientProtocolHandler implements MRClientProtocol {

    private RecordFactory recordFactory = 
      RecordFactoryProvider.getRecordFactory(null);

    @Override
    public InetSocketAddress getConnectAddress() {
      return getBindAddress();
    }
    
    private Job verifyAndGetJob(JobId jobID, JobACL accessType,
        boolean exceptionThrow) throws IOException {
      Job job = appContext.getJob(jobID);
      if (job == null && exceptionThrow) {
        throw new IOException("Unknown Job " + jobID);
      }
      UserGroupInformation ugi = UserGroupInformation.getCurrentUser();
      if (job != null && !job.checkAccess(ugi, accessType)) {
        throw new AccessControlException("User " + ugi.getShortUserName()
            + " cannot perform operation " + accessType.name() + " on "
            + jobID);
      }
      return job;
    }
 
    private Task verifyAndGetTask(TaskId taskID, 
        JobACL accessType) throws IOException {
      Task task =
          verifyAndGetJob(taskID.getJobId(), accessType, true).getTask(taskID);
      if (task == null) {
        throw new IOException("Unknown Task " + taskID);
      }
      return task;
    }

    private TaskAttempt verifyAndGetAttempt(TaskAttemptId attemptID, 
        JobACL accessType) throws IOException {

View on GitHub (pinned to 2add963021)

Solutions

  1. Run the client as the job owner, or have the owner set mapreduce.job.acl-view-job / mapreduce.job.acl-modify-job to a group/user list containing the caller
  2. Widen access centrally via mapreduce.cluster.acl-view-job / mapreduce.cluster.acl-modify-job if the policy allows it
  3. If you are the admin, verify the caller is actually resolved to the admin group (group mapping) before expecting override

Example fix

// before
job.getTaskReports(TaskType.MAP); // AccessControlException for non-owner

// after - submitting user grants view access
conf.set(JobContext.JOB_ACL_VIEW_JOB, "analytics,ops");
Defensive patterns

Strategy: try-catch

Try / catch

try {
  job.getCounters(); // any AM RPC that passes verifyAndGetJob
} catch (AccessControlException ace) {
  // message shape: 'User <u> cannot perform operation <ACL> on <jobId>'
  if (ace.getMessage().contains("cannot perform operation")) {
    // fall back: rerun as owner, or read via JHS if only view was denied
  }
  throw ace;
}

Prevention

When it happens

Trigger: A non-owner user calls getCounters/getTaskReport/killJob on the AM without being in the job ACL; job ACLs default to ' ' (empty) so nobody but owner/admins pass; cluster administrators property restricts who counts as admin.

Common situations: Support tooling or monitoring daemons running under a service account querying other users' jobs; shared clusters where mapreduce.job.acl-view-job was never set; users expecting to see teammates' jobs without configuring job ACLs.

Related errors


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