How To Fix Jenkins Failing to Start After Disabling RBAC Plugin

Everything was running smoothly on my Jenkins server until I enabled Role-Based Access Control (RBAC) to manage developer permissions.
After adding a new “Developer” user through the Role Strategy Plugin, I noticed that user permissions weren’t working as expected.

To troubleshoot, I deactivated the plugin — and that’s when the real trouble began.

The Problem

After disabling the RBAC plugin, Jenkins refused to start.
Checking the service status showed this:

systemctl status jenkins.service

× jenkins.service - Jenkins Continuous Integration Server
  Loaded: loaded (/lib/systemd/system/jenkins.service; enabled)
  Active: failed (Result: exit-code)
  Process: 291330 ExecStart=/usr/bin/jenkins (code=exited, status=5)

When I checked the logs (journalctl -u jenkins), I found this clue:

CannotResolveClassException: com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy

That was the smoking gun 🔫 — Jenkins was still trying to load the Role Strategy plugin, even though I had uninstalled it.

Root Cause

Jenkins stores its configuration in /var/lib/jenkins/config.xml.
Inside that file, there’s an XML block called <authorizationStrategy> that defines which security model Jenkins should use.

When the RBAC plugin was installed, this block looked like this:

<authorizationStrategy class="com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy">
   ...
</authorizationStrategy>

So when the plugin was removed, Jenkins couldn’t find the class RoleBasedAuthorizationStrategy — and failed to start completely.

The Fix

Step 1: Backup the Jenkins Configuration

Always back up your configuration before editing:

cp /var/lib/jenkins/config.xml /var/lib/jenkins/config.xml.bak

Step 2: Edit the Configuration File

Open the file in your favorite editor:

nano /var/lib/jenkins/config.xml

Find and replace the entire authorization block with this safe, built-in strategy:

<authorizationStrategy class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy">
  <denyAnonymousReadAccess>false</denyAnonymousReadAccess>
</authorizationStrategy>

This change tells Jenkins to use the default “full control once logged in” model and ignore the missing plugin.

Step 3: Restart Jenkins

Reload and restart the service:

systemctl daemon-reload
systemctl restart jenkins
systemctl status jenkins -l

Within a few seconds, Jenkins should be back up and running.

Conclusion

Jenkins’ flexibility is both a blessing and a curse.
While plugins make it incredibly powerful, removing or disabling them can sometimes break things if the configuration still references them.

By resetting the authorizationStrategy in config.xml, Jenkins was back online without losing any jobs, builds, or pipelines.

A small XML edit saved hours of rebuild time!