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
- Validate arguments before the call: require at least one of owner/group, or make null mean 'no-op' and skip the call entirely.
- Default the null field to the current value from getFileStatus(p).getOwner()/getGroup() when intent is 'set one, keep other'.
- Fix the upstream config/metadata that produced nulls.
- 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
- Model 'unchanged' explicitly in wrapper APIs (Optional/absent) instead of null.
- Validate ownership-change requests at the tool's argument parsing layer.
- When copying metadata, fetch current owner/group first and substitute them for nulls.
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
- Permission denied: user=%s, path="%s":%s:%s:%s%s
- {} doesn't support modifyAclEntries
- {} doesn't support removeAclEntries
- {} doesn't support removeAcl
- {} doesn't support setAcl
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/4d4987da1e576830.
Report an issue: GitHub.