apache/hadoop · error · IOException

Failed to set permissions of path: " + p + " to " + String.f

Error message

Failed to set permissions of path: " + p + " to " + String.format("%04o", permission.toShort())

What it means

checkReturnValue is used by FileUtil's pure-Java permission setter: it calls File.setReadable/Writable/Executable and if any returns false it throws IOException("Failed to set permissions of path: <p> to <octal>") with the FsPermission rendered via String.format("%04o", permission.toShort()). File.set* returns false (rather than throwing) when the operation is unsupported or disallowed — typically the caller is not the file's owner, or the filesystem does not implement POSIX mode bits.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileUtil.java:1514

    if (group.implies(FsAction.WRITE) != user.implies(FsAction.WRITE)) {
      rv = f.setWritable(user.implies(FsAction.WRITE), true);
      checkReturnValue(rv, f, permission);
    }

    // exec perms
    rv = f.setExecutable(group.implies(FsAction.EXECUTE), false);
    checkReturnValue(rv, f, permission);
    if (group.implies(FsAction.EXECUTE) != user.implies(FsAction.EXECUTE)) {
      rv = f.setExecutable(user.implies(FsAction.EXECUTE), true);
      checkReturnValue(rv, f, permission);
    }
  }

  private static void checkReturnValue(boolean rv, File p,
                                       FsPermission permission
                                       ) throws IOException {
    if (!rv) {
      throw new IOException("Failed to set permissions of path: " + p +
                            " to " +
                            String.format("%04o", permission.toShort()));
    }
  }

  private static void execSetPermission(File f,
                                        FsPermission permission
                                       )  throws IOException {
    if (NativeIO.isAvailable()) {
      NativeIO.POSIX.chmod(f.getCanonicalPath(), permission.toShort());
    } else {
      execCommand(f, Shell.getSetPermissionCommand(
                  String.format("%04o", permission.toShort()), false));
    }
  }

  static String execCommand(File f, String... cmd) throws IOException {
    String[] args = new String[cmd.length + 1];

View on GitHub (pinned to 2add963021)

Solutions

Run the operation as the file's owner (or root) so File.set* is permitted
Pre-fix ownership with FileUtil.setOwner/fileSystem.setOwner, then apply permissions
Use a POSIX-compliant filesystem for paths whose permissions matter, and ensure NativeIO is available so the chmod path uses NativeIO.POSIX.chmod instead
Avoid permission bits java.io cannot represent (setuid/sticky) on this code path; use RawLocalFileSystem.setPermission if you need them

Example fix

// before
FileUtil.setPermission(new File("/data/part-0"),
    FsPermission.valueOf("rw-r-----")); // not owner -> IOException

// after: chown first (as a permitted identity), then chmod
FileUtil.setOwner(new File("/data/part-0"), currentUser, null);
FileUtil.setPermission(new File("/data/part-0"),
    FsPermission.valueOf("rw-r-----"));

Defensive patterns

Strategy: try-catch

Validate before calling

File f = new File(path);
if (!f.canWrite()) throw new IOException("No write access to " + f);
if (!Files.isPosix(f.toPath().getFileSystem().supportedFileAttributeViews()
        .contains("posix"))) {
  throw new IOException("POSIX permissions unsupported on this filesystem");
}

Type guard

static boolean canSetPosixPermissions(File f) throws IOException {
  return f.getCanonicalFile().toPath().getFileSystem()
      .supportedFileAttributeViews().contains("posix");
}

Try / catch

try {
  FileUtil.setPermission(f, perm);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("Failed to set permissions")) {
    // not owner or non-POSIX fs: chown first as an authorized identity, or move
    // the data to a POSIX filesystem and retry
  } else throw e;
}

Prevention

Run permission changes as the file owner or root
Keep permissioned data on POSIX filesystems where NativeIO is available
Avoid bits java.io cannot express (setuid/sticky) on this path

When it happens

Trigger: FileUtil.setPermission / setPermissions (non-NativeIO path) run by a user who does not own the file; filesystem without POSIX permissions (FAT32, some NTFS configurations, certain network/object mounts); attempting setuid/setsticky bits the java.io API cannot express (e.g. 1777 on /tmp-like dirs fails here).

Common situations: Services started as one user chowning/chmodding files created by another; Windows or exFAT data volumes; containers running as non-root against root-owned files; setting 01777-style permissions on staging dirs.

Related errors

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