pentaho/pentaho-kettle · error · KettleException

: permission not allowed

Error message

 : permission not allowed

What it means

checkOperationAllowed throws when isAllowed(operation) returns false, producing '<operation> : permission not allowed'. This is Pentaho repository security explicitly denying the operation (e.g. 'create', 'read', 'update', 'delete' on repository objects) for the connected user — the check ran fine but access was refused. It is surfaced from validateAction, which the pur repository delegates call before every repository mutation/read.

Solutions

  1. Grant the connected user's role the required Pentaho repository permission (e.g. Create/Read/Update/Delete) in the Pentaho User Console.
  2. Verify you are connected as the intended user — re-enter credentials or inspect Repository.connect.
  3. Test the exact action with the admin account to confirm it is a permission mapping issue and not content corruption.
  4. Check repository security backend settings (jackrabbit/security policy) if using a custom security provider.
  5. If the denial is expected, wrap the repository call in try-catch and handle the KettleException gracefully in your automation.

Example fix

// before
repository.save(transMeta, "v1", null); // throws '<operation> : permission not allowed'
// after
try {
  repository.validateAction(RepositoryOperation.MODIFY_TRANSFORMATION);
  repository.save(transMeta, "v1", null);
} catch (KettleException e) {
  throw new IllegalStateException("User lacks repository permission to save: " + e.getMessage(), e);
}
Defensive patterns

Strategy: try-catch

Validate before calling

// check the user's role/permissions before attempting the repository operation
repository.validateAction(RepositoryOperation.MODIFY_TRANSFORMATION); // pre-flight

Try / catch

try {
  repository.save(transMeta, versionComment, null);
} catch (KettleException e) {
  if (e.getMessage() != null && e.getMessage().endsWith(": permission not allowed")) {
    throw new SecurityException("Repository permission denied: " + e.getMessage(), e);
  }
  throw e;
}

Prevention

When it happens

Trigger: Any pur repository operation (saving a transformation/job, reading metadata, deleting content) via validateAction when the connected Pentaho user's role lacks the required repository security action, e.g. trying to save into a repository where the user has read-only rights or is a guest.

Common situations: Connecting as a user without Admin/Creator role; repository security mapping missing the required permission for the user's role; executing PDI jobs unattended with a service account that has restricted ACLs; tenant/workspace permission changes made on the server.

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 pentaho/pentaho-kettle@f3058517a1 (2026-09-13). Data as JSON: /api/errors/c75cd27f1608a8a9. Report an issue: GitHub.

Appendix: source

Thrown at plugins/pur/core/src/main/java/org/pentaho/di/repository/pur/AbsSecurityProvider.java:109

          break;

        case MODIFY_DATABASE:
          checkOperationAllowed( MODIFY_DATABASE_ACTION );
          break;

        case SCHEDULER_EXECUTE:
          checkOperationAllowed( SCHEDULER_EXECUTE_ACTION );
          break;
      }
    }
  }

  /**
   * @throws KettleException if an operation is not allowed
   */
  private void checkOperationAllowed( String operation ) throws KettleException {
    if ( !isAllowed( operation ) ) {
      throw new KettleException( operation + " : permission not allowed" );
    }
  }

}

View on GitHub (pinned to f3058517a1)