apache/hadoop · error · IOException

The option dfs.namenode.support.allow.format is set to false

Error message

The option dfs.namenode.support.allow.format is set to false for this filesystem, so it cannot be formatted. You will need to set dfs.namenode.support.allow.format parameter to true in order to format this filesystem

What it means

NameNode.checkAllowFormat throws IOException unless dfs.namenode.support.allow.format is true (it defaults to true). Clusters set it to false on NameNodes that must never be formatted - e.g., HA nodes sharing edits via QJM - so any format attempt against such a node fails with this message naming the exact key.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java:1439

        return true; // aborted
      }

      fsImage.format(fsn, clusterId, force);
    } catch (IOException ioe) {
      LOG.warn("Encountered exception during format", ioe);
      throw ioe;
    } finally {
      if (fsn != null) {
        fsn.close();
      }
    }
    return false;
  }

  public static void checkAllowFormat(Configuration conf) throws IOException {
    if (!conf.getBoolean(DFS_NAMENODE_SUPPORT_ALLOW_FORMAT_KEY, 
        DFS_NAMENODE_SUPPORT_ALLOW_FORMAT_DEFAULT)) {
      throw new IOException("The option " + DFS_NAMENODE_SUPPORT_ALLOW_FORMAT_KEY
                + " is set to false for this filesystem, so it "
                + "cannot be formatted. You will need to set "
                + DFS_NAMENODE_SUPPORT_ALLOW_FORMAT_KEY +" parameter "
                + "to true in order to format this filesystem");
    }
  }
  
  @VisibleForTesting
  public static boolean initializeSharedEdits(Configuration conf) throws IOException {
    return initializeSharedEdits(conf, true);
  }
  
  @VisibleForTesting
  public static boolean initializeSharedEdits(Configuration conf,
      boolean force) throws IOException {
    return initializeSharedEdits(conf, force, false);
  }

View on GitHub (pinned to 2add963021)

Solutions

1. Run the format on a node where formatting is allowed, or temporarily set dfs.namenode.support.allow.format=true on the target node, format, then set it back to false.
2. For HA, prefer formatting one node and bootstrapping peers with 'hdfs namenode -bootstrapStandby'.
3. If the format was accidental, no harm was done - the guard did its job; verify and continue with existing metadata.

Example fix

<!-- before: hdfs-site.xml -->
<property><name>dfs.namenode.support.allow.format</name><value>false</value></property>
hdfs namenode -format   # fails

<!-- after -->
<property><name>dfs.namenode.support.allow.format</name><value>true</value></property>
hdfs namenode -format   # then restore false after the intentional format

// check the guard before attempting format
if (!conf.getBoolean(DFS_NAMENODE_SUPPORT_ALLOW_FORMAT_KEY, DFS_NAMENODE_SUPPORT_ALLOW_FORMAT_DEFAULT)) {
  throw new IllegalStateException(
      "dfs.namenode.support.allow.format=false on this node - format here is forbidden by policy");
}

boolean isAllowFormatGuard(IOException e) {
  return String.valueOf(e.getMessage()).contains("dfs.namenode.support.allow.format");
}

When it happens

Trigger: 'hdfs namenode -format' on a NameNode whose hdfs-site.xml sets dfs.namenode.support.allow.format=false; the flag exists precisely to make accidental format impossible on shared-edits/HA deployments.

Common situations: HA production clusters hardened against accidental format; operator runs format on the wrong node; bootstrap automation targeting a node with the guard set.

Related errors

• NameNode format aborted as reformat is disabled for this clu
• Configuration has multiple addresses that match local node's
• Configuration dfs.namenode.rpc-address must be suffixed with
• Multiple shared edits directories are not yet supported
• HA for namenode is not enabled

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