apache/hadoop · error · AccessControlException
Permission denied: user=%s, path="%s":%s:%s:%s%s
Error message
Permission denied: user=%s, path="%s":%s:%s:%s%s
What it means
AccessControlException from FileSystem.access(Path, FsAction). The default implementation loads FileStatus, resolves the calling UserGroupInformation, and evaluates POSIX owner/group/other bits in that order; if the applicable class does not imply the requested action it throws this message containing: calling user, path, owner, group, 'd' for directory or '-' for file, and the full permission string. It is the client-side mirror of what the NameNode enforces server-side.
Source
Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java:2874
static void checkAccessPermissions(FileStatus stat, FsAction mode)
throws AccessControlException, IOException {
FsPermission perm = stat.getPermission();
UserGroupInformation ugi = UserGroupInformation.getCurrentUser();
String user = ugi.getShortUserName();
if (user.equals(stat.getOwner())) {
if (perm.getUserAction().implies(mode)) {
return;
}
} else if (ugi.getGroupsSet().contains(stat.getGroup())) {
if (perm.getGroupAction().implies(mode)) {
return;
}
} else {
if (perm.getOtherAction().implies(mode)) {
return;
}
}
throw new AccessControlException(String.format(
"Permission denied: user=%s, path=\"%s\":%s:%s:%s%s", user, stat.getPath(),
stat.getOwner(), stat.getGroup(), stat.isDirectory() ? "d" : "-", perm));
}
/**
* See {@link FileContext#fixRelativePart}.
* @param p the path.
* @return relative part.
*/
protected Path fixRelativePart(Path p) {
if (p.isUriPathAbsolute()) {
return p;
} else {
return new Path(getWorkingDirectory(), p);
}
}
/**View on GitHub (pinned to 2add963021)
Solutions
- Read the message — it prints user, path, owner:group and the exact permission bits; grant precisely what is missing (hdfs dfs -chmod o+rx <path>, -chown, or -setfacl -m user:<u>:rw- when ACLs are enabled)
- If the user should qualify via group: add them on the group source (LDAP/etc.), then hdfs dfsadmin -refreshUserToGroupsMappings or restart long-running services holding the cache
- For local/dev runs align the identity with HADOOP_USER_NAME=<owner>
- Avoid widening 'other' bits — prefer ACL entries for specific users
Example fix
# before # throws: Permission denied: user=etl, path="/data/warehouse/failure_logs":hive:hadoop:d--------- hdfs dfs -put failures.log /data/warehouse/failure_logs # after (grant group write, refresh mappings if group membership changed) hdfs dfs -chmod 775 /data/warehouse/failure_logs hdfs dfs -setfacl -m user:etl:rwx /data/warehouse/failure_logs hdfs dfs -put failures.log /data/warehouse/failure_logs
Defensive patterns
Strategy: try-catch
Validate before calling
try {
fs.access(path, FsAction.WRITE); // same POSIX evaluation, throws ACE with details
} catch (AccessControlException e) {
throw new SecurityException("Insufficient rights for " + path + ": " + e.getMessage(), e);
} Try / catch
} catch (AccessControlException e) {
// e.getMessage() already names user, path, owner:group and perm bits.
// Remediate (chmod/chown/setfacl, refresh group mappings, correct user) — do not blind-retry.
} Prevention
- Set service scratch/staging dirs to permissive group bits (e.g., 775) with a sane umask at creation time
- After usermod/group changes, run hdfs dfsadmin -refreshUserToGroupsMappings and restart long-lived clients
- For local dev, start the JVM with HADOOP_USER_NAME set to the data owner
- Preflight with fs.access() and fail with the decoded message before submitting a long job
When it happens
Trigger: fs.access(p, FsAction.READ|WRITE|EXECUTE) where the mode bits deny the caller's class: caller is not the owner, is not in the file's group (ugi.getGroupsSet() check), and 'other' bits are insufficient; e.g. WRITE against perms 755 for a non-owner, or EXECUTE missing on a parent directory component. Also reached through FileContext and tools that preflight access before I/O.
Common situations: Job user lacks +x on a parent directory; data chowned to a different service account; user added to a group but the NameNode's group mapping cache is stale; local integration tests running as a different OS user than the data owner; restrictive umask (027/077) on Hive/Spark scratch dirs.
Related errors
- {} doesn't support modifyAclEntries
- {} doesn't support removeAclEntries
- {} doesn't support removeAcl
- {} doesn't support setAcl
- Cannot remove directory {}
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/f42b14670a50d3eb.
Report an issue: GitHub.