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
- 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.
- Check disk space ('df -h <name-dir>') and mount flags ('mount | grep <dir>'); free space or remount read-write.
- Ensure exactly one NameNode process is running ('jps', pid files); kill the stale one holding or recreating the directory.
- 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
- Run a write/canary test as the NN user in every dfs.namenode.name.dir before upgrade windows.
- Disk-space and mount-read-only alerts on name volumes; upgrades blocked while alerts fire.
- Enforce single-NameNode-per-storage-dir with fencing (format/node id checks) so a second process cannot race the rename.
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
- Cannot create directory {}
- Mkdirs failed to create {}
- Mkdirs failed to create ${dir}
- Cannot create directory ${aliasMapFile}
- Permission denied: user=%s, path="%s":%s:%s:%s%s
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/cabd9c556c2b5390.
Report an issue: GitHub.