apache/hadoop · error · IOException

Security is enabled but block access tokens (via dfs.block.a

Error message

Security is enabled but block access tokens (via dfs.block.access.token.enable) aren't enabled. This may cause issues when clients attempt to connect to a DataNode. Aborting NameNode

What it means

In BlockManager block-access-token initialization, when dfs.block.access.token.enable is false the NameNode checks UserGroupInformation.isSecurityEnabled(): with Kerberos security on but block tokens off, it throws IOException and aborts NameNode startup. Without block tokens under Kerberos, DataNodes cannot mutually authenticate block operations, which silently breaks clients, so the NameNode refuses to start rather than run in a broken-secure mode.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java:716

    LOG.info("encryptDataTransfer        = {}", encryptDataTransfer);
    LOG.info("maxNumBlocksToLog          = {}", maxNumBlocksToLog);
  }

  private static BlockTokenSecretManager createBlockTokenSecretManager(
      final Configuration conf) throws IOException {
    final boolean isEnabled = conf.getBoolean(
        DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_ENABLE_KEY, 
        DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_ENABLE_DEFAULT);
    LOG.info("{} = {}", DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_ENABLE_KEY,
            isEnabled);

    if (!isEnabled) {
      if (UserGroupInformation.isSecurityEnabled()) {
        String errMessage = "Security is enabled but block access tokens " +
            "(via " + DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_ENABLE_KEY + ") " +
            "aren't enabled. This may cause issues " +
            "when clients attempt to connect to a DataNode. Aborting NameNode";
        throw new IOException(errMessage);
      }
      return null;
    }

    final long updateMin = conf.getLong(
        DFSConfigKeys.DFS_BLOCK_ACCESS_KEY_UPDATE_INTERVAL_KEY, 
        DFSConfigKeys.DFS_BLOCK_ACCESS_KEY_UPDATE_INTERVAL_DEFAULT);
    final long lifetimeMin = conf.getLong(
        DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_LIFETIME_KEY, 
        DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_LIFETIME_DEFAULT);
    final String encryptionAlgorithm = conf.get(
        DFSConfigKeys.DFS_DATA_ENCRYPTION_ALGORITHM_KEY);
    LOG.info("{}={} min(s), {}={} min(s), {}={}",
        DFSConfigKeys.DFS_BLOCK_ACCESS_KEY_UPDATE_INTERVAL_KEY, updateMin,
        DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_LIFETIME_KEY, lifetimeMin,
        DFSConfigKeys.DFS_DATA_ENCRYPTION_ALGORITHM_KEY, encryptionAlgorithm);
    
    String nsId = DFSUtil.getNamenodeNameServiceId(conf);

View on GitHub (pinned to 2add963021)

Solutions

Set dfs.block.access.token.enable=true in hdfs-site.xml on all nodes (it must be consistent cluster-wide)
Restart the NameNode (and roll DataNodes with the updated config)
If this was a deliberate insecure test setup, instead disable Kerberos (hadoop.security.authentication=simple) - but never run security-on with tokens-off

Example fix

<!-- before -->
<property><name>dfs.block.access.token.enable</name><value>false</value></property>

<!-- after -->
<property><name>dfs.block.access.token.enable</name><value>true</value></property>

Defensive patterns

Strategy: validation

Validate before calling

static void validateSecureHdfsConf(Configuration conf) {
  boolean securityOn = "kerberos".equalsIgnoreCase(conf.get("hadoop.security.authentication", "simple"));
  boolean tokensOff = !conf.getBoolean(DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_ENABLE_KEY, DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_ENABLE_DEFAULT);
  if (securityOn && tokensOff) throw new IllegalStateException("Kerberos enabled but dfs.block.access.token.enable=false; NameNode will abort");
}

Try / catch

catch (IOException e) { if (e.getMessage().contains("block access tokens")) failDeploymentWithFix(e, "set dfs.block.access.token.enable=true"); else throw e; }

Prevention

Treat dfs.block.access.token.enable=true as mandatory in every secure (Kerberos) cluster template
Run the pairwise check (hadoop.security.authentication vs block tokens) as a pre-flight in config-management pipelines
Roll hdfs-site.xml and core-site.xml security settings in the same change window to avoid mismatched states

When it happens

Trigger: core-site.xml has hadoop.security.authentication=kerberos (security enabled) while hdfs-site.xml leaves dfs.block.access.token.enable=false (or explicitly false), then the NameNode starts.

Common situations: Enabling Kerberos on an existing cluster but missing this hdfs-site.xml step in the guide; config management roles (Puppet/Chef/Ansible) that roll hdfs-site.xml before core-site security settings; fresh secure-cluster installs from an insecure template.

Related errors

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