apache/hadoop · critical · java.io.IOException
All specified directories are not accessible or do not exist
Error message
All specified directories are not accessible or do not exist.
What it means
At NameNode startup, FSImage.recoverTransitionRead() resolved the image dirs (dfs.namenode.name.dir) and edits dirs (dfs.namenode.edits.dir) and one of the two collections came up empty — no usable configured directory — while the startup option is not IMPORT. With nowhere to read or write metadata the NameNode refuses to start rather than silently formatting something.
Source
Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSImage.java:237
* Perform fs state transition if necessary depending on the namespace info.
* Read storage info.
*
* @throws IOException
* @return true if the image needs to be saved or false otherwise
*/
boolean recoverTransitionRead(StartupOption startOpt, FSNamesystem target,
MetaRecoveryContext recovery)
throws IOException {
assert startOpt != StartupOption.FORMAT :
"NameNode formatting should be performed before reading the image";
Collection<URI> imageDirs = storage.getImageDirectories();
Collection<URI> editsDirs = editLog.getEditURIs();
// none of the data dirs exist
if((imageDirs.size() == 0 || editsDirs.size() == 0)
&& startOpt != StartupOption.IMPORT)
throw new IOException(
"All specified directories are not accessible or do not exist.");
// 1. For each data directory calculate its state and
// check whether all is consistent before transitioning.
Map<StorageDirectory, StorageState> dataDirStates =
new HashMap<StorageDirectory, StorageState>();
boolean isFormatted = recoverStorageDirs(startOpt, storage, dataDirStates);
if (LOG.isTraceEnabled()) {
LOG.trace("Data dir states:\n " +
Joiner.on("\n ").withKeyValueSeparator(": ")
.join(dataDirStates));
}
if (!isFormatted && startOpt != StartupOption.ROLLBACK
&& startOpt != StartupOption.IMPORT) {
throw new IOException("NameNode is not formatted.");
}View on GitHub (pinned to 2add963021)
Solutions
- Check the effective config on the failing host: hdfs getconf -confKey dfs.namenode.name.dir and hdfs getconf -confKey dfs.namenode.edits.dir.
- Set valid URIs (e.g. file:///dfs/hadoop/hdfs/namenode, or qjournal://jn1:8485;jn2:8485;jn3:8485/mycluster for HA) and confirm HADOOP_CONF_DIR is right.
- Create the directories with correct ownership (usually hdfs:hdfs) and writable permissions.
- If this is a brand-new cluster, format once the config is fixed: hdfs namenode -format.
Example fix
<!-- before: no storage configured --> <property><name>dfs.namenode.name.dir</name><value></value></property> <!-- after --> <property> <name>dfs.namenode.name.dir</name> <value>file:///dfs/hadoop/hdfs/namenode</value> </property> <property> <name>dfs.namenode.edits.dir</name> <value>qjournal://jn1:8485;jn2:8485;jn3:8485/mycluster</value> </property>
Defensive patterns
Strategy: validation
Validate before calling
for (String key : new String[]{
DFSConfigKeys.DFS_NAMENODE_NAME_DIR_KEY,
DFSConfigKeys.DFS_NAMENODE_EDITS_DIR_KEY}) {
Collection<String> vals = conf.getTrimmedStringCollection(key);
if (vals.isEmpty()) {
throw new IllegalStateException(key + " resolved to no directories");
}
} Prevention
- Automate preflight checks for name.dir/edits.dir before every NameNode start.
- Use 'hdfs getconf' to diff effective config across nodes.
- Never ship an empty <value/> for storage location keys.
When it happens
Trigger: dfs.namenode.name.dir or dfs.namenode.edits.dir unset, empty, or resolving to zero URIs for this nameservice (typical in HA/federation misconfiguration); config file not picked up because HADOOP_CONF_DIR points elsewhere; property name typos.
Common situations: Fresh deployment with incomplete hdfs-site.xml; HA setup where the local edits dir list is empty because only a shared dir was intended but misnamed; empty-string overrides from templating; running the NameNode host with the wrong environment.
Related errors
- Unknown nameservice: {}
- Configuration has multiple addresses that match local node's
- Configuration dfs.namenode.rpc-address must be suffixed with
- Cannot lock storage {root}. The directory is already locked
- Incompatible node types: storageType={storageType} but Stora
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/722c61c2c144e77a.
Report an issue: GitHub.