apache/hadoop · error · IOException

username == null && groupname == null

Error message

username == null && groupname == null

What it means

setOwner(Path, String username, String groupname) requires at least one of username or groupname to be non-null; passing both as null is a contract violation with no valid RPC to send, so the client throws IOException('username == null && groupname == null') before contacting the NameNode. This is a local argument-validation failure, not a cluster error.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java:2119

      public Void doCall(final Path p) throws IOException {
        dfs.setPermission(getPathName(p), permission);
        return null;
      }

      @Override
      public Void next(final FileSystem fs, final Path p)
          throws IOException {
        fs.setPermission(p, permission);
        return null;
      }
    }.resolve(this, absF);
  }

  @Override
  public void setOwner(Path p, final String username, final String groupname)
      throws IOException {
    if (username == null && groupname == null) {
      throw new IOException("username == null && groupname == null");
    }
    statistics.incrementWriteOps(1);
    storageStatistics.incrementOpCounter(OpType.SET_OWNER);
    Path absF = fixRelativePart(p);
    new FileSystemLinkResolver<Void>() {
      @Override
      public Void doCall(final Path p) throws IOException {
        dfs.setOwner(getPathName(p), username, groupname);
        return null;
      }

      @Override
      public Void next(final FileSystem fs, final Path p)
          throws IOException {
        fs.setOwner(p, username, groupname);
        return null;
      }
    }.resolve(this, absF);

View on GitHub (pinned to 2add963021)

Solutions

  1. Validate arguments before the call: require at least one of owner/group, or make null mean 'no-op' and skip the call entirely.
  2. Default the null field to the current value from getFileStatus(p).getOwner()/getGroup() when intent is 'set one, keep other'.
  3. Fix the upstream config/metadata that produced nulls.
  4. If writing a wrapper API, overload setOwner into setOwnerOnly/setGroupOnly variants that never see two nulls.

Example fix

// before
fs.setOwner(path, newOwner, newGroup); // both may be null -> IOException

// after
if (newOwner == null && newGroup == null) {
  return; // nothing to change
}
fs.setOwner(path, newOwner, newGroup);
Defensive patterns

Strategy: validation

Validate before calling

if (username != null || groupname != null) {
  fs.setOwner(path, username, groupname);
} // else: no-op, do not call

Try / catch

try {
  fs.setOwner(path, user, group);
} catch (IOException e) {
  if (!"username == null && groupname == null".equals(e.getMessage())) throw e;
  // skip: nothing requested
}

Prevention

When it happens

Trigger: Calling setOwner(p, null, null) — typically from code that reads owner/group from config or a metadata file and forwards nulls unchecked, or a chown-like tool invoked with neither -user nor -group.

Common situations: Distcp/permission-sync tools that copy owner/group fields and pass null when the source metadata lacks them; wrappers that map 'keep unchanged' to null; CLI-ish tools where optional flags leave both fields unset.

Related errors


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