apache/hadoop · critical · IOException

No storage directories contained VERSION information

Error message

No storage directories contained VERSION information

What it means

After readProperties has looped over every current storage directory, a still-null layoutVersion means no directory produced readable VERSION data at all. NNStorage refuses to proceed because nothing about the on-disk format is known - effectively 'no usable storage' rather than a problem with one dir.

Source

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

      StorageDirectory sd = it.next();
      if (!sd.getVersionFile().exists()) {
        FSImage.LOG.warn("Storage directory " + sd +
            " contains no VERSION file. Skipping...");
        continue;
      }
      readProperties(sd, startupOption); // sets layoutVersion
      int lv = getLayoutVersion();
      if (layoutVersion == null) {
        layoutVersion = lv;
      } else if (!layoutVersion.equals(lv)) {
        multipleLV = true;
      }
      layoutVersions.append("(").append(sd.getRoot()).append(", ").append(lv)
          .append(") ");
    }
    
    if (layoutVersion == null) {
      throw new IOException("No storage directories contained VERSION" +
          " information");
    }
    if (multipleLV) {            
      throw new IOException(
          "Storage directories contain multiple layout versions: "
              + layoutVersions);
    }
    // If the storage directories are with the new layout version
    // (ie edits_<txnid>) then use the new inspector, which will ignore
    // the old format dirs.
    FSImageStorageInspector inspector;
    if (NameNodeLayoutVersion.supports(
        LayoutVersion.Feature.TXID_BASED_LAYOUT, getLayoutVersion())) {
      inspector = new FSImageTransactionalStorageInspector(fileTypes);
    } else {
      inspector = new FSImagePreTransactionalStorageInspector();
    }

View on GitHub (pinned to 2add963021)

Solutions

Confirm formatting was done and where: 'hdfs getconf -nameDirs', then ls <dir>/current/VERSION for each.
Restore from backup or sibling copies, or run 'hdfs namenode -format' only if the cluster is genuinely new (it destroys data).
Fix mounts and paths so the NN sees the formatted storage, then restart.

Defensive patterns

Strategy: validation

Validate before calling

// Pre-start check: at least one readable VERSION with a layout version
boolean any = false;
for (String loc : conf.getTrimmedStrings("dfs.namenode.name.dir")) {
  Map<String, String> p = parseVersion(Paths.get(stripScheme(loc), "current", "VERSION"));
  if (p.containsKey("layoutVersion")) { any = true; break; }
}
if (!any) throw new IllegalStateException("No readable VERSION in any name dir - format or restore before start");

Prevention

Gate NN start on a pre-start script verifying at least one formatted dir.
Double-check mount points and effective dfs.namenode.name.dir after environment clones.
Keep offline copies of name dirs for restore drills.

When it happens

Trigger: Every dfs.namenode.name.dir is empty, unformatted, corrupt or unmounted when the NN starts (or during recovery/rollback scans); alternatively the config points at paths that never held this cluster's storage.

Common situations: Fresh install without format; wrong mount(s) or paths in a new environment; all VERSION files removed after an incident; config drift pointing NN at scratch dirs.

Related errors

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