apache/hadoop · error · IOException

Owner '{}' for path {} did not match expected owner '{}'

Error message

Owner '{}' for path {} did not match expected owner '{}'

What it means

checkFileOwner throws this IOException when the actual owner of a local file differs from the expectedOwner argument passed to SecureIOUtils.openForRead/openForWrite. The check prevents swapped or tampered local files from being trusted. On Windows there is a carve-out: the check passes if the real owner is 'Administrators' and the remote user belongs to the Administrators group; otherwise any mismatch fails.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/SecureIOUtils.java:299

  private static void checkStat(File f, String owner, String group, 
      String expectedOwner, 
      String expectedGroup) throws IOException {
    boolean success = true;
    if (expectedOwner != null &&
        !expectedOwner.equals(owner)) {
      if (Path.WINDOWS) {
        UserGroupInformation ugi =
            UserGroupInformation.createRemoteUser(expectedOwner);
        final String adminsGroupString = "Administrators";
        success = owner.equals(adminsGroupString)
            && ugi.getGroupsSet().contains(adminsGroupString);
      } else {
        success = false;
      }
    }
    if (!success) {
      throw new IOException(
          "Owner '" + owner + "' for path " + f + " did not match " +
              "expected owner '" + expectedOwner + "'");
    }
  }

  /**
   * Signals that an attempt to create a file at a given pathname has failed
   * because another file already existed at that path.
   */
  public static class AlreadyExistsException extends IOException {
    private static final long serialVersionUID = 1L;

    public AlreadyExistsException(String msg) {
      super(msg);
    }

    public AlreadyExistsException(Throwable cause) {
      super(cause);

View on GitHub (pinned to 2add963021)

Solutions

  1. Fix ownership: chown expectedOwner:group on the file and its directory
  2. Ensure the job is submitted/run as the user that owns the files (kinit as that user, check proxy user settings)
  3. Delete the offending scratch file so it is regenerated under the right owner
  4. On Windows hosts, run the client under a user in the Administrators group so the special case applies

Example fix

// before
FSDataInputStream in = SecureIOUtils.openForRead(f, "jobuser"); // owner mismatch IOException

// after
UserPrincipal owner = Files.getOwner(f.toPath());
if (!"jobuser".equals(owner.getName())) {
  throw new IOException(f + " owned by " + owner.getName() + "; run: chown jobuser " + f);
}
FSDataInputStream in = SecureIOUtils.openForRead(f, "jobuser");
Defensive patterns

Strategy: try-catch

Validate before calling

String actual = Files.getOwner(f.toPath()).getName();
if (!expectedOwner.equals(actual)
    && !(Path.WINDOWS && "Administrators".equals(actual)
        && UserGroupInformation.createRemoteUser(expectedOwner).getGroupsSet().contains("Administrators"))) {
  throw new IOException(f + " owned by " + actual + ", expected " + expectedOwner);
}

Try / catch

try {
  in = SecureIOUtils.openForRead(f, expectedOwner);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().contains("did not match expected owner")) {
    // ownership problem: chown or delete-and-regenerate, then retry
  } else { throw e; }
}

Prevention

When it happens

Trigger: openForRead(file, expectedOwner) where file's POSIX owner is a different account: local dirs owned by another user, files copied between hosts preserving wrong ownership, or a daemon writing under a different effective user than the job owner.

Common situations: Someone ran chown -R over hadoop local/data dirs; jobs submitted as user A while the NodeManager dirs were created by user B; backups restored with altered ownership; NFS mounts with root-squash rewriting owners.

Related errors


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