apache/dolphinscheduler · error · ServiceException
user %s doesn't have permission of %s %s
Error message
user %s doesn't have permission of %s %s
What it means
PermissionCheck.checkPermission, for non-admin users, asks processService.listUnauthorized which of the checked resources (by authorizationType) the user does NOT own. If any are unauthorized it throws a ServiceException naming the user, the resource type description, and the first unauthorized resource. This is the generic resource-ownership guard on APIs like task definition release.
Source
Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/permission/PermissionCheck.java:86
*
* @throws ServiceException exception
*/
public void checkPermission() throws ServiceException {
if (this.needChecks.length > 0) {
// get user type in order to judge whether the user is admin
User user = processService.getUserById(userId);
if (user == null) {
logger.error("User does not exist, userId:{}.", userId);
throw new ServiceException(String.format("user %s doesn't exist", userId));
}
if (user.getUserType() != UserType.ADMIN_USER) {
List<T> unauthorizedList = processService.listUnauthorized(userId, needChecks, authorizationType);
// if exist unauthorized resource
if (CollectionUtils.isNotEmpty(unauthorizedList)) {
logger.error("User does not have {} permission for {}, userName:{}.",
authorizationType.getDescp(), unauthorizedList, user.getUserName());
throw new ServiceException(String.format("user %s doesn't have permission of %s %s",
user.getUserName(), authorizationType.getDescp(), unauthorizedList.get(0)));
}
}
}
}
}
View on GitHub (pinned to 02eac45a1b)
Solutions
- Grant the user access to the resource (project authorization: grant project/task-definition permission in the UI or via grant APIs)
- Perform the operation as the resource owner or as an admin
- Check the log line 'User does not have ... permission for ...' to see the exact unauthorized resource
- If ownership is wrong, transfer the resource to the intended owner
Example fix
// before: direct call fails for non-owner permissionCheck.checkPermission(userId, AuthorizationType.TASK_DEFINITION, taskCode); // after: ensure grant exists first projectService.checkProjectAndAuth(loginUser, project, projectName); permissionCheck.checkPermission(userId, AuthorizationType.TASK_DEFINITION, taskCode);
Defensive patterns
Strategy: try-catch
Validate before calling
// caller-side pre-check
List<T> unauthorized = processService.listUnauthorized(userId, needChecks, authorizationType);
if (!unauthorized.isEmpty()) {
throw new ServiceException("no permission on " + unauthorized.get(0));
} Type guard
boolean hasAllPermissions(User user, Object... resourceIds) {
if (user == null || user.getUserType() == UserType.ADMIN_USER) return true;
return processService.listUnauthorized(user.getId(), resourceIds, authorizationType).isEmpty();
} Try / catch
try {
permissionCheck.checkPermission(userId, taskCode, AuthorizationType.TASK_DEFINITION);
} catch (ServiceException e) {
if (e.getMessage().contains("doesn't have permission of")) {
log.warn("grant required: {}", e.getMessage());
throw new ServiceStatusHttpException(Status.USER_NO_OPERATION_PERM, e);
}
throw e;
} Prevention
- Grant project/resource permissions before sharing tasks across teams
- Use the resource-owner or admin account for administrative operations
- Read the error's unauthorized resource list to request exactly the right grant
- Regularly audit ownership transfers after team member changes
When it happens
Trigger: A non-admin user calls an operation (e.g. releaseTaskDefinition) on a resource (task definition, project, datasource...) whose owner is another user, and the id/code is in needChecks.
Common situations: Sharing a task URL between colleagues without granting project permission; a user renamed/transferred resources; automation using a service account that doesn't own the resources.
Understand the failure class
Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.
Related errors
AI-assisted analysis of apache/dolphinscheduler@02eac45a1b (2026-09-06).
Data as JSON: /api/errors/df3b64608bdfe71a.
Report an issue: GitHub.