apache/hadoop · error · IOException

MR AM not authorized to issue delegation token

Error message

MR AM not authorized to issue delegation token

What it means

MRClientService.getDelegationToken unconditionally throws this IOException: the MR ApplicationMaster never issues delegation tokens. Token issuance is a JobHistoryServer capability (HSClientService implements getDelegationToken for the history service); the AM only authorizes via job ACLs plus Kerberos. Any client that follows the generic MRClientProtocol token path against the AM endpoint gets rejected by design.

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:424

      Collection<Task> tasks = job.getTasks(taskType).values();
      LOG.info("Getting task report for " + taskType + "   " + jobId
          + ". Report-size will be " + tasks.size());

      // Take lock to allow only one call, otherwise heap will blow up because
      // of counters in the report when there are multiple callers.
      synchronized (getTaskReportsLock) {
        for (Task task : tasks) {
          response.addTaskReport(task.getReport());
        }
      }

      return response;
    }

    @Override
    public GetDelegationTokenResponse getDelegationToken(
        GetDelegationTokenRequest request) throws IOException {
      throw new IOException("MR AM not authorized to issue delegation" +
      		" token");
    }

    @Override
    public RenewDelegationTokenResponse renewDelegationToken(
        RenewDelegationTokenRequest request) throws IOException {
      throw new IOException("MR AM not authorized to renew delegation" +
          " token");
    }

    @Override
    public CancelDelegationTokenResponse cancelDelegationToken(
        CancelDelegationTokenRequest request) throws IOException {
      throw new IOException("MR AM not authorized to cancel delegation" +
          " token");
    }
  }

View on GitHub (pinned to 2add963021)

Solutions

  1. Point the token request at the Job History Server (historyServiceAddress from the job or mapreduce.jobhistory.address) which does issue tokens
  2. Skip DT acquisition for AM calls and authenticate with Kerberos instead — the AM's verifyAndGetJob path only needs an authenticated UGI plus job ACLs
  3. If you must act for another user, use the doAs/proxy pattern on a Kerberos-authenticated connection rather than a delegation token

Example fix

// before - asking the ApplicationMaster
GetDelegationTokenResponse resp = amProtocol.getDelegationToken(req);

// after - ask the Job History Server, which implements token issuance
GetDelegationTokenResponse resp = hsProtocol.getDelegationToken(req);
Defensive patterns

Strategy: fallback

Try / catch

try {
  token = protocol.getDelegationToken(new GetDelegationTokenRequest()).getDelegationToken();
} catch (IOException e) {
  if (e.getMessage().contains("not authorized to issue delegation token")) {
    token = null; // AM never issues DTs: fall back to Kerberos auth or JHS
  } else { throw e; }
}

Prevention

When it happens

Trigger: Client calls protocol.getDelegationToken(GetDelegationTokenRequest) on the AM tracking address; token-renewal-aware wrappers (e.g., long-lived proxy users) automatically request a DT from every MR protocol endpoint they touch.

Common situations: Porting MRv1-era clients that fetched job tokens from the JobTracker; Oozie/secure-proxy style code requesting DTs before reading job status; hitting the AM instead of the JHS because both speak MRClientProtocol.

Related errors

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