apache/hadoop · error · DiskErrorException

Directory is not executable: ${dir}

Error message

Directory is not executable: ${dir}

What it means

checkAccessByFileMethods rejects a storage directory whose FileUtil.canExecute(dir) returns false, throwing DiskErrorException('Directory is not executable: <dir>'). For directories the execute bit is traverse permission — without it the daemon cannot stat or descend into paths under the directory, so it is treated as bad.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/DiskChecker.java:171

  private static void checkAccessByFileMethods(File dir)
      throws DiskErrorException {
    if (!dir.isDirectory()) {
      throw new DiskErrorException("Not a directory: "
          + dir.toString());
    }

    if (!FileUtil.canRead(dir)) {
      throw new DiskErrorException("Directory is not readable: "
                                   + dir.toString());
    }

    if (!FileUtil.canWrite(dir)) {
      throw new DiskErrorException("Directory is not writable: "
                                   + dir.toString());
    }

    if (!FileUtil.canExecute(dir)) {
      throw new DiskErrorException("Directory is not executable: "
                                   + dir.toString());
    }
  }

  /**
   * The semantics of mkdirsWithExistsCheck method is different from the mkdirs
   * method provided in the Sun's java.io.File class in the following way:
   * While creating the non-existent parent directories, this method checks for
   * the existence of those directories if the mkdir fails at any point (since
   * that directory might have just been created by some other process).
   * If both mkdir() and the exists() check fails for any seemingly
   * non-existent directory, then we signal an error; Sun's mkdir would signal
   * an error (return false) if a directory it is attempting to create already
   * exists or the mkdir fails.
   * @param dir
   * @return true on success, false on failure
   */
  private static boolean mkdirsWithExistsCheck(File dir) {

View on GitHub (pinned to 2add963021)

Solutions

1. Add the traverse bit: chmod u+x <dir> (or chmod 755) as appropriate
2. Fix recursive mode changes: directories need x (find <root> -type d -exec chmod 755 {} +)
3. Verify as the daemon user: sudo -u yarn ls <dir>/subdir
4. Review the umask under which the daemon creates storage dirs

Example fix

# before: a recursive chmod stripped the traverse bit
chmod -R 644 /data/nm-local
# after: restore x on directories only
find /data/nm-local -type d -exec chmod 755 {} +

import java.nio.file.*;
for (String dir : configuredDirs) {
  Path p = Paths.get(dir);
  if (!Files.isExecutable(p)) {
    throw new IllegalStateException("directory lacks traverse (x) permission: " + dir);
  }
}

When it happens

Trigger: Directory mode lacks the execute/traverse bit (e.g. 644); overly restrictive umask when the directory was auto-created; hardening scripts applying file modes to directories.

Common situations: chmod 644 applied recursively to a tree including directories; dirs created under umask 0777-style policies; containers where base images ship non-traversable dirs.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

• Cannot create directory: ${dir}
• Directory is not readable: ${dir}
• Directory is not writable: ${dir}
• Not a directory: ${dir}
• Failed to delete ${file}

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