apache/hadoop · error · IOException

Unable to rename {} to {}

Error message

Unable to rename {} to {}

What it means

Complementary recovery path in the pre-transactional inspector: fsimage.ckpt exists but edits.new is gone (the interrupted checkpoint got further), so recovery completes the checkpoint by renaming fsimage.ckpt to fsimage. If the rename and the retry (after deleting the destination) both fail, this IOException aborts startup. Same environmental causes: permissions, cross-device rename semantics, or a locked destination file.

Source

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

        // before the namenode crashed.
        //
        if (!ckptFile.delete()) {
          throw new IOException("Unable to delete " + ckptFile);
        }
      } else {
        //
        // checkpointing was in progress when the namenode
        // shutdown. The fsimage.ckpt was created and the edits.new
        // file was moved to edits. We complete that checkpoint by
        // moving fsimage.new to fsimage. There is no need to 
        // update the fstime file here. renameTo fails on Windows
        // if the destination file already exists.
        //
        if (!ckptFile.renameTo(curFile)) {
          if (!curFile.delete())
            LOG.warn("Unable to delete dir " + curFile + " before rename");
          if (!ckptFile.renameTo(curFile)) {
            throw new IOException("Unable to rename " + ckptFile +
                                  " to " + curFile);
          }
        }
      }
    }
    return needToSave;
  }
  
  /**
   * @return a list with the paths to EDITS and EDITS_NEW (if it exists)
   * in a given storage directory.
   */
  static List<File> getEditsInStorageDir(StorageDirectory sd) {
    ArrayList<File> files = new ArrayList<File>();
    File edits = NNStorage.getStorageFile(sd, NameNodeFile.EDITS);
    assert edits.exists() : "Expected edits file at " + edits;
    files.add(edits);
    File editsNew = NNStorage.getStorageFile(sd, NameNodeFile.EDITS_NEW);

View on GitHub (pinned to 2add963021)

Solutions

1. Fix ownership and write permission on the whole current/ directory for the NN user
2. Close/unlock anything holding fsimage open; verify no second NameNode is running on the same dirs
3. Manually finish the recovery after confirming edits.new is absent: mv fsimage.ckpt fsimage, then restart
4. Keep name storage on a single filesystem; avoid symlink tricks across devices

Example fix

# before: rename fails, ckpt stranded
ls /dfs/name/current/   # fsimage.ckpt present, edits.new absent, no fsimage
# after: complete the checkpoint by hand and restart
mv /dfs/name/current/fsimage.ckpt /dfs/name/current/fsimage
su - hdfs -c 'hdfs --daemon start namenode'

File cur = new File(nameDir, "current");
if (!Files.isWritable(cur.toPath())) throw new IOException("not writable: " + cur);
// rename round-trip check on the same filesystem
File probe = File.createTempFile("nn", ".probe", cur);
if (!probe.renameTo(new File(probe.getAbsolutePath() + ".r"))) {
  throw new IOException("rename not permitted in " + cur);
}

When it happens

Trigger: ckptFile.renameTo(curFile) returns false twice during doRecovery() while fsimage.ckpt exists and edits.new does not — permission errors, destination held open (Windows renameTo also fails when the destination exists), or source/destination on different filesystems.

Common situations: current/ directory not writable by the NN user; another process (second NN, OIV) holds fsimage open; name storage split across symlinked mounts.

Related errors

• Unable to delete {}
• Image file is not found in {}
• Edits file is not found in {}
• Inconsistent storage detected, image and edits checkpoint ti
• Unexpected HAServiceStateProto:

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