apache/dolphinscheduler · error · ServiceException

USER_NO_OPERATION_PERM

USER_NO_OPERATION_PERM

Error message

USER_NO_OPERATION_PERM: user has no operation permission

What it means

USER_NO_OPERATION_PERM is thrown by deleteSchedulesById when the login user is neither the creator of the schedule (loginUser.getId() != schedule.getUserId()) nor an admin (UserType.ADMIN_USER). Ownership plus project write permission (checked afterwards via projectPermCheckByWorkflowCode) are required to delete someone else's schedule.

Source

Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/SchedulerServiceImpl.java:360

    /**
     * delete schedule by id
     *
     * @param loginUser   login user
     * @param scheduleId  schedule id
     */
    @Override
    public void deleteSchedulesById(User loginUser, Integer scheduleId) {
        Schedule schedule = scheduleDao.queryById(scheduleId);
        if (schedule == null) {
            throw new ServiceException(Status.SCHEDULE_NOT_EXISTS, scheduleId);
        }
        // check schedule is already online
        if (schedule.getReleaseState() == ReleaseState.ONLINE) {
            throw new ServiceException(Status.SCHEDULE_STATE_ONLINE, scheduleId);
        }
        // Determine if the login user is the owner of the schedule
        if (loginUser.getId() != schedule.getUserId() && loginUser.getUserType() != UserType.ADMIN_USER) {
            throw new ServiceException(Status.USER_NO_OPERATION_PERM);
        }

        this.projectPermCheckByWorkflowCode(loginUser, schedule.getWorkflowDefinitionCode());
        boolean delete = scheduleDao.deleteById(scheduleId);
        if (!delete) {
            throw new ServiceException(Status.DELETE_SCHEDULE_BY_ID_ERROR);
        }
    }

    /**
     * preview schedule
     *
     * @param loginUser login user
     * @param schedule  schedule expression
     * @return the next five fire time
     */
    @Override
    public List<String> previewSchedule(User loginUser, String schedule) {

View on GitHub (pinned to 02eac45a1b)

Solutions

  1. Log in / authenticate as the schedule owner or as an admin user and retry.
  2. Grant the user project write permission (and have an admin delete the schedule if ownership transfer is not possible).
  3. Delete the schedule as ADMIN via the admin account, or recreate the schedule under the correct owner.

Example fix

// before
curl -u viewer:token -X DELETE '/projects/1/schedules/42'   // viewer != owner
// after
curl -u admin:token -X DELETE '/projects/1/schedules/42'
Defensive patterns

Strategy: validation

Validate before calling

boolean allowed = loginUser.getUserType() == UserType.ADMIN_USER
        || Objects.equals(loginUser.getId(), schedule.getUserId());
if (!allowed) {
    throw new SecurityException("User " + loginUser.getUserName() + " may not delete schedule owned by " + schedule.getUserId());
}

Try / catch

try { schedulerService.deleteSchedulesById(user, scheduleId); } catch (ServiceException e) { if (e.getCode() == Status.USER_NO_OPERATION_PERM) { /* escalate to admin or re-authenticate as owner */ } }

Prevention

When it happens

Trigger: DELETE /projects/{projectCode}/schedules/{id} called by a non-admin user who did not create the schedule, e.g. a project member with view-only rights, or a service account whose token belongs to a different user than the schedule owner.

Common situations: Automation using a generic API account while schedules were created by individual users; offboarding scripts cleaning up schedules they don't own; team members with read permissions attempting deletions; permission model changed in an upgrade so formerly-allowed deletes now fail.

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/b097f183207f1737. Report an issue: GitHub.