Unable to apply more than 3 permissions per security group

I am currently experiencing an issue where we are only able to apply 3 permissions to a group. For example, I can have the below 3 permissions added, and the roles.ini file gets parsed correctly, but if I add anything else after the 3 module for module/monitoring, we will then see an exception at the top of the Icinga web page stated an incorrect syntax.

Couldn’t parse the INI file `/etc/icingaweb2/roles.ini’
syntax error, unexpected ‘"’ in Unknown on line 13

For example, here is a set of permissions that works:
groups = “Operator-Admins”
permissions = “module/businessprocess, module/grafana, module/monitoring”

If adding an additional permission, such as monitoring/command/schedule-check, we will see the following when attempting to go into Settings → Access Control.

Here is what appears to break access to that location:
groups = “Operator-Admins”
permissions = “module/businessprocess, module/grafana, module/monitoring, monitoring/command/schedule-check”

And this goes for ANY permission added after the 3rd permission. We can adjust the 3 permissions to be anything we would like, but a 4th one breaks it causing an exception.

Unfortunately, we only have the ability to edit these permissions via the config-map roles.ini file, and not directly in Icinga, as even though we have full permissions for everything, we get an access denied.

Give as much information as you can, e.g.

  • Icinga Web 2 version - 2.11.4
  • Used modules and their versions (System - About) - Grafana, Icingadb, Monitoring
  • Web browser used - Chrome, Edge, etc
  • Icinga 2 version used (icinga2 --version) - 2.11.4
  • PHP version used (php --version) - 8.1.2-1ubuntu2.13
  • Server operating system and version - Ubuntu Linux


this seems to be caused by the newline your example includes, if that’s by intent.

We don’t know of any similar issue, nor can I personally reproduce this in my environment.

Is there maybe something mangling the file regarding line length?

Interestingly, this appeared to be due to Rancher/Kubernetes, where if we edited the config for roles.ini it would throw an exception. If we edited the .yaml file then everything worked as expected.

So, the problem is solved? Though, which .yaml are you speaking of?

Yes it is. There is a .yaml file within our kubernetes Icinga container that drives the configuration for our Icinga Monitoring.