apache/hadoop · error · IOException

Cannot remove current directory: {curDir}

Error message

Cannot remove current directory: {curDir}

What it means

Storage.StorageDirectory.clearDirectory() wipes and recreates current/ during format, rollback and finalize transitions: it lists the files, calls FileUtil.fullyDelete(curDir), and if the recursive delete fails it throws IOException('Cannot remove current directory: <curDir>'). The listed files are logged ('Will remove files: ...') just before, which is the fastest way to see what could not be deleted.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/common/Storage.java:444

     * This does not fully format storage directory. 
     * It cannot write the version file since it should be written last after  
     * all other storage type dependent files are written.
     * Derived storage is responsible for setting specific storage values and
     * writing the version file to disk.
     * 
     * @throws IOException
     */
    public void clearDirectory() throws IOException {
      File curDir = this.getCurrentDir();
      if (curDir == null) {
        // if the directory is null, there is nothing to do.
        return;
      }
      if (curDir.exists()) {
        File[] files = FileUtil.listFiles(curDir);
        LOG.info("Will remove files: {}", Arrays.toString(files));
        if (!(FileUtil.fullyDelete(curDir)))
          throw new IOException("Cannot remove current directory: " + curDir);
      }
      if (!curDir.mkdirs()) {
        throw new IOException("Cannot create directory " + curDir);
      }
      if (permission != null) {
        try {
          Set<PosixFilePermission> permissions =
              PosixFilePermissions.fromString(permission.toString());
          Files.setPosixFilePermissions(curDir.toPath(), permissions);
        } catch (UnsupportedOperationException uoe) {
          // Default to FileUtil for non posix file systems
          FileUtil.setPermission(curDir, permission);
        }
      }
    }

    /**
     * Directory {@code current} contains latest files defining

View on GitHub (pinned to 2add963021)

Solutions

  1. Stop the daemon that owns the storage directory and confirm nothing holds files open (lsof +<pid> or check in_use.lock removed)
  2. Fix ownership/permissions: chown -R <hdfs-user> <storage-dir> and ensure write access
  3. Repair the filesystem layer: remount read-write mounts, resolve NFS stale handles, check dmesg/RAID health
  4. As a last resort, delete current/ manually (after backing up) and re-run format

Example fix

# before: format fails deleting current/
sudo -u hdfs hdfs namenode -format   # old NN still running

# after
hadoop-daemon.sh stop namenode
lsof +D /dfs/nn/current || true
sudo chown -R hdfs:hdfs /dfs/nn
sudo -u hdfs hdfs namenode -format
Defensive patterns

Strategy: try-catch

Validate before calling

File curDir = sd.getCurrentDir();
if (curDir != null && curDir.exists()) {
  if (!Files.isWritable(curDir.getParentFile().toPath())) {
    throw new IOException("Storage parent not writable: " + curDir.getParent());
  }
  try (Stream<Path> s = Files.list(curDir.toPath())) {
    Path lock = curDir.toPath().resolve("in_use.lock");
    if (Files.exists(lock)) throw new IOException("Lock present; daemon still running?");
  }
}
sd.clearDirectory();

Try / catch

try {
  sd.clearDirectory();
} catch (IOException e) {
  if (e.getMessage().startsWith("Cannot remove current directory")) {
    throw new IOException("Stop the owning daemon and fix permissions on "
        + sd.getCurrentDir(), e); // actionable rethrow
  } else throw e;
}

Prevention

When it happens

Trigger: Running 'hdfs namenode -format' (or DataNode initialization/rollback/finalize) while the process cannot delete everything under current/: another process still holds a file (in_use.lock, replica files) via an open handle, permissions/ownership changed, or the storage filesystem is read-only or erroring (NFS stale handles, disk fault).

Common situations: Formatting without stopping the old NameNode/DataNode; running the daemon under a different user than the storage dir's owner; storage on NFS with stale file handles; a filesystem remounted read-only after errors.

Related errors


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