apache/hadoop · error · DiskErrorException

Directory is not writable: ${dir}

Error message

Directory is not writable: ${dir}

What it means

checkAccessByFileMethods rejects a storage directory whose FileUtil.canWrite(dir) returns false, throwing DiskErrorException('Directory is not writable: <dir>'). Without the write bit the daemon cannot create files or subdirectories, so the directory fails the health check.

Source

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

   * 
   * @param dir File to check
   * @throws DiskErrorException if dir is not readable, not writable, or not
   *   executable
   */
  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

View on GitHub (pinned to 2add963021)

Solutions

  1. Add the write bit: chmod u+w <dir> (or chmod 755) as appropriate
  2. chown the directory to the daemon user/group
  3. Confirm the filesystem is mounted read-write (mount | grep <dir>)
  4. Re-test with sudo -u <daemon> touch <dir>/.probe

Example fix

# before
sudo -u hdfs touch /data/dfs/dn/.probe   # Permission denied
# after
sudo chmod 755 /data/dfs/dn && sudo chown hdfs:hadoop /data/dfs/dn && sudo -u hdfs touch /data/dfs/dn/.probe
Defensive patterns

Strategy: validation

Validate before calling

import java.nio.file.*;
for (String dir : configuredDirs) {
  Path p = Paths.get(dir);
  if (!Files.isWritable(p)) {
    throw new IllegalStateException("directory not writable by " + System.getProperty("user.name") + ": " + dir);
  }
}

Prevention

When it happens

Trigger: Directory mode lacks the write bit for the daemon user (e.g. 555); directory owned by another user; a read-only mount even when mode bits look fine.

Common situations: Storage dirs created by provisioning tools as root; umask/settings producing read-only dirs; volumes remounted read-only after an fsck or disk error.

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


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