apache/hadoop · error · IOException

No delegation token found for this identifier

Error message

No delegation token found for this identifier

What it means

DelegationTokenSecretManager.getTokenExpiryTime throws IOException when asked for the expiry of a DelegationTokenIdentifier that is not in currentTokens. Tokens live in currentTokens only while valid: the expired-token reaper removes them after maxLifetime, cancellation removes them immediately, and a restarted/reloaded secret manager only knows tokens persisted in fsimage. A miss therefore means expired, canceled, unknown-to-this-NN, or state not yet loaded.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/security/token/delegation/DelegationTokenSecretManager.java:160

        throw it;
      }
    }
  }
  
  /**
   * Returns expiry time of a token given its identifier.
   * 
   * @param dtId DelegationTokenIdentifier of a token
   * @return Expiry time of the token
   * @throws IOException
   */
  public synchronized long getTokenExpiryTime(
      DelegationTokenIdentifier dtId) throws IOException {
    DelegationTokenInformation info = currentTokens.get(dtId);
    if (info != null) {
      return info.getRenewDate();
    } else {
      throw new IOException("No delegation token found for this identifier");
    }
  }

  /**
   * Load SecretManager state from fsimage.
   * 
   * @param in input stream to read fsimage
   * @throws IOException
   */
  public synchronized void loadSecretManagerStateCompat(DataInput in)
      throws IOException {
    if (running) {
      // a safety check
      throw new IOException(
          "Can't load state from image in a running SecretManager.");
    }
    serializerCompat.load(in);
  }

View on GitHub (pinned to 2add963021)

Solutions

  1. Have the client catch the IOException and treat it as 'token invalid': obtain a new delegation token (re-login with kerberos and request via WebHDFS/HDFS RPC getDelegationToken) and retry.
  2. For schedulers of long jobs, renew well before dfs.delegation.token.max-lifetime and re-fetch before renew window closes; never cache tokens beyond max lifetime.
  3. In HA setups confirm both NameNodes (shared edits) have the token; query the Active that issued/last renewed it.
  4. If you expected the token to still be valid, check the canceler in NN audit logs and the token lifetime configuration (dfs.delegation.token.renew-interval / max-lifetime).

Example fix

// before
long expiry = dtSecretManager.getTokenExpiryTime(identifier); // IOException: No delegation token found

// after
long expiry;
try {
  expiry = dtSecretManager.getTokenExpiryTime(identifier);
} catch (IOException e) {
  // token unknown/expired/canceled -> fetch a fresh one
  Token<DelegationTokenIdentifier> t = getNewDelegationToken(nn, user);
  expiry = dtSecretManager.getTokenExpiryTime(t.decodeIdentifier());
}
Defensive patterns

Strategy: try-catch

Try / catch

try {
  long expiry = dtSecretManager.getTokenExpiryTime(identifier);
} catch (IOException e) {
  if ("No delegation token found for this identifier".equals(e.getMessage())) {
    // token expired/canceled/unknown: reacquire a delegation token and retry
    token = fetchNewDelegationToken();
  } else { throw e; }
}

Prevention

When it happens

Trigger: getTokenExpiryTime(dtId) is called for an identifier that was never added or was removed — renewing/canceling after expiry, querying a token issued by the other HA NameNode before state propagated, or checking a token against a fresh NN that has not loaded the checkpoint containing it.

Common situations: Client lets a delegation token expire (default 7d max lifetime) then attempts renew; token canceled by another client; HA failover where the new Active's token state differs; Spark/Hive/oozie long-lived jobs holding tokens across expiry; tools inspecting token expiry against the wrong NameNode.

Related errors


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