apache/dolphinscheduler · error · ServiceException

20016

20016

Error message

resource not exist or no permission,please view the task node and remove error resource

What it means

TaskDatasourcePermissionChecker.checkPermission validates that the task's referenced datasource ids are usable by the caller. It delegates to resourcePermissionCheckService.resourcePermissionCheck for AuthorizationType.DATASOURCE (admins pass userId=0 which checks existence only). On failure it throws ServiceException with Status.RESOURCE_NOT_EXIST_OR_NO_PERMISSION (code 20016).

Source

Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/permission/TaskDatasourcePermissionChecker.java:84

            if (datasourceResources == null) {
                continue;
            }
            datasourceResources.keySet().stream()
                    .filter(datasourceId -> datasourceId != null && datasourceId > 0)
                    .forEach(datasourceIds::add);
        }

        if (datasourceIds.isEmpty()) {
            return;
        }

        int userId = loginUser.getUserType() == UserType.ADMIN_USER ? 0 : loginUser.getId();
        Integer[] datasourceIdArray = datasourceIds.toArray(new Integer[0]);
        if (!resourcePermissionCheckService.resourcePermissionCheck(
                AuthorizationType.DATASOURCE, datasourceIdArray, userId, log)) {
            log.warn("User does not have permission to use datasource referenced by task, userId:{}.",
                    loginUser.getId());
            throw new ServiceException(Status.RESOURCE_NOT_EXIST_OR_NO_PERMISSION);
        }
    }
}

View on GitHub (pinned to 02eac45a1b)

Solutions

Open the task node and remove or replace the invalid/unauthorized datasource reference
Grant the user permission to the datasource (UI: Security -> Datasource -> grant)
Verify the datasource id still exists in t_ds_datasource
If you are the admin checking existence, confirm the datasource wasn't deleted

Example fix

// before: datasourceIds kept from copied task
taskDefinitionService.updateTask(...);
// after: pre-check in caller
Integer[] ids = params.getDatasourceIds();
if (!resourcePermissionCheckService.resourcePermissionCheck(AuthorizationType.DATASOURCE, ids, loginUser.getId(), log)) {
    throw new ServiceException(Status.RESOURCE_NOT_EXIST_OR_NO_PERMISSION);
}

Defensive patterns

Strategy: validation

Validate before calling

// before saving a task definition
for (Integer dsId : taskParams.getDatasourceIds()) {
    DataSource ds = dataSourceService.getDataSource(dsId);
    if (ds == null) throw new ServiceException("datasource " + dsId + " not exist");
    if (loginUser.getUserType() != UserType.ADMIN_USER && ds.getUserId() != loginUser.getId()) {
        throw new ServiceException("no permission on datasource " + dsId);
    }
}

Type guard

boolean canUseDatasources(User loginUser, List<Integer> ids) {
    int userId = loginUser.getUserType() == UserType.ADMIN_USER ? 0 : loginUser.getId();
    return resourcePermissionCheckService.resourcePermissionCheck(
        AuthorizationType.DATASOURCE, ids.toArray(new Integer[0]), userId, log);
}

Try / catch

try {
    taskDefinitionService.updateTaskDefinition(...);
} catch (ServiceException e) {
    if (e.getCode() == Status.RESOURCE_NOT_EXIST_OR_NO_PERMISSION.getCode()) {
        log.warn("fix datasource references in task node before saving");
    }
    throw e;
}

Prevention

Re-validate datasource references after copying tasks between users/projects
Warn before deleting a datasource still referenced by tasks
Re-check permissions when switching accounts from admin to normal user
Keep datasource ids out of hand-edited JSON

When it happens

Trigger: Saving/updating a task definition whose datasourceIds reference a datasource that either no longer exists or is owned by another user (non-admin).

Common situations: A datasource was deleted while tasks still reference it; a colleague's task copied into your workflow without being granted the datasource; switching from admin to normal user changes the check from existence-only to ownership.

Understand the failure class

Background: "You do not have permission" / 403 Forbidden errors: authenticated but not allowed — causes and fixes across open-source libraries — this error's family across 31 libraries.

Related errors

AI-assisted analysis of apache/dolphinscheduler@02eac45a1b (2026-09-06). Data as JSON: /api/errors/7551c58949ed97bf. Report an issue: GitHub.