apache/hadoop · error · IOException

Cannot create directory {curDir}

Error message

Cannot create directory {curDir}

What it means

Thrown by NNUpgradeUtil.doPreUpgrade during an upgrade. The code first renames 'current' to 'previous.tmp' (after Preconditions confirmed current existed and previous/previous.tmp did not), then calls curDir.mkdir() to create a fresh 'current'. If mkdir() returns false, the IOException is raised: the storage directory's parent is not writable, the filesystem is read-only or full, or a concurrent process raced the rename.

Source

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

   */
  public static void renameCurToTmp(StorageDirectory sd) throws IOException {
    File curDir = sd.getCurrentDir();
    File prevDir = sd.getPreviousDir();
    final File tmpDir = sd.getPreviousTmp();

    Preconditions.checkState(curDir.exists(),
        "Current directory must exist for preupgrade.");
    Preconditions.checkState(!prevDir.exists(),
        "Previous directory must not exist for preupgrade.");
    Preconditions.checkState(!tmpDir.exists(),
        "Previous.tmp directory must not exist for preupgrade."
            + "Consider restarting for recovery.");

    // rename current to tmp
    NNStorage.rename(curDir, tmpDir);

    if (!curDir.mkdir()) {
      throw new IOException("Cannot create directory " + curDir);
    }
  }
  
  /**
   * Perform the upgrade of the storage dir to the given storage info. The new
   * storage info is written into the current directory, and the previous.tmp
   * directory is renamed to previous.
   * 
   * @param sd the storage directory to upgrade
   * @param storage info about the new upgraded versions.
   * @throws IOException in the event of error
   */
  public static void doUpgrade(StorageDirectory sd, Storage storage)
      throws IOException {
    LOG.info("Performing upgrade of storage directory " + sd.getRoot());
    try {
      // Write the version file, since saveFsImage only makes the
      // fsimage_<txid>, and the directory is otherwise empty.

View on GitHub (pinned to 2add963021)

Solutions

  1. Verify ownership and write permission of every dfs.namenode.name.dir / dfs.namenode.edits.dir for the NN user: 'sudo -u hdfs ls -ld <dir>'; fix with chown/chmod.
  2. Check disk space ('df -h <name-dir>') and mount flags ('mount | grep <dir>'); free space or remount read-write.
  3. Ensure exactly one NameNode process is running ('jps', pid files); kill the stale one holding or recreating the directory.
  4. If the failure left 'previous.tmp' behind, restarting the NameNode triggers recovery of the interrupted rename before retrying the upgrade (the Preconditions message hints at this).

Example fix

// before
sudo -u hdfs hdfs namenode -upgrade   # NN user cannot write the name dir

// after
chown -R hdfs:hdfs /data/dfs/name
chmod 700 /data/dfs/name
sudo -u hdfs hdfs namenode -upgrade
Defensive patterns

Strategy: validation

Validate before calling

// pre-flight before 'hdfs namenode -upgrade'
for (Path p : nameDirs) {
  File f = new File(p.toString());
  if (!Files.isWritable(f.getParentFile().toPath()))
    throw new IllegalStateException("name dir not writable: " + f);
  if (f.getUsableSpace() < MIN_BYTES) throw new IllegalStateException("low disk: " + f);
}
Files.list(dir).filter(n -> n.getFileName().toString().startsWith("previous")).forEach(n -> fail("stale previous dir: " + n));

Prevention

When it happens

Trigger: 'hdfs namenode -upgrade' (or journal node / storage-dir upgrade path calling doPreUpgrade) where the NameNode user cannot create 'current' after the rename: no write permission on the name dir, ENOSPC, a read-only or NFS-ro mount, or a second NameNode process recreating 'current' between rename and mkdir.

Common situations: Name dirs owned by root while NN runs as 'hdfs'; disk full on the name volume; NFS/SAN mount mounted read-only during maintenance; accidentally starting two NameNode processes against the same dfs.namenode.name.dir.

Related errors


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