RuntimeException: Adding non-existent permissions to a role is not allowed.

Looks like this was some stale perms in existing config for a user causing the error, not field permissions.

Just ran into the same issue. @realityloop could you perhaps provide some details, what's the exact problem and how to fix it?

I guess future users will also come to this field_permissions related issue (even if it's not the root cause) and it would be nice to know how this can be resolved. I was able to reproduce it like in the issue summary, but not yet to fix it.

Update:
@realityloop is correct in #6! The reasons are stale permissions left in the user.role.X configs (user.role.administrator.yml e.g.). Which ones are affected is shown in the error message.

To resolve it, edit these configs and delete these lines.

Alternatively it MIGHT also work to just resave the permission matrix at /admin/people/permissions - I didn't try that, so perhaps someone who runs into this could try and tell if it works. That would be a lot easier.

Still I wonder if field_permission should trigger this, if "Not set" is selected? But I didn't dig deep enough to tell about it.

Update2:
Ran into this again and re-saving the permission matrix is not possible, as it runs into the same error.

Anyway it looks like this issue only happens in combination with this module and in my case now it's the field permissions of a field that I deleted minutes ago. They don't seem to have been deleted correctly, which seems to cause the issue!

The field was named: field_user_company and was placed on a non-bundled entity (user)

RuntimeException: Adding non-existent permissions to a role is not allowed. The incorrect permissions are "create field_user_company", "edit field_user_company", "edit own field_user_company", "view field_user_company", "view own field_user_company". in Drupal\user\Entity\Role->calculateDependencies() (line 207 of core/modules/user/src/Entity/Role.php).

Drupal\Core\Config\Entity\ConfigEntityBase->preSave() (Line: 179)
Drupal\user\Entity\Role->preSave() (Line: 528)
Drupal\Core\Entity\EntityStorageBase->doPreSave() (Line: 483)
Drupal\Core\Entity\EntityStorageBase->save() (Line: 253)
Drupal\Core\Config\Entity\ConfigEntityStorage->save() (Line: 339)
Drupal\Core\Entity\EntityBase->save() (Line: 608)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 96)
Drupal\field_permissions\Plugin\FieldPermissionType\CustomAccess->submitAdminForm() (Line: 155)
field_permission_field_config_edit_form_submit()
call_user_func_array() (Line: 114)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 52)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult() (Line: 39)
Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 49)
Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 686)
Drupal\Core\DrupalKernel->handle() (Line: 19)

So I'm reopening this for further investigations.

In my case, I had deleted a paragraph type: paragraph_pagepiling_block. It affected not only my ability to edit the permissions but my ck-editor (configure/Content Authoring/Text formatters and editors) where I couldn't change and save anything.

Turns out the permission for allowing full-html formatting in the paragraph's full text field was the culprit. I solved the problem by creating a new paragraph_pagepiling_block and reestablishing the same fields, setting the full-html formatter in the text field. I suspect that if I remove that full-html and set it to Plain text, saving and run updates, that I could safely delete the culprit.

But no time for that now.

Thanks to @anybody and @realityloop, I was able to fix my issues identical to #9. For anonymity, all private data is [in_brackets]

In config, I had the file:
user.role.[role].yml

In that file was:

uuid: [uuid]
langcode: en
status: true
dependencies:
  module:
    - field_permissions
id: [role_id]
label: '[role_label]'
weight: 11
is_admin: null
permissions:
  - 'create field_[field_name]'
  - 'edit field_[field_name]'
  - 'edit own field_[field_name]'
  - 'view field_[field_name]'
  - 'view own field_[field_name]'

I simply deleted this block:

permissions:
  - 'create field_[field_name]'
  - 'edit field_[field_name]'
  - 'edit own field_[field_name]'
  - 'view field_[field_name]'
  - 'view own field_[field_name]'

...and ran another 'drush cim' (drush import)

Then, the import ran successfully and no more errors

 [notice] Synchronized configuration: update user.role.[role].
 [notice] Finalizing configuration synchronization.
 [success] The configuration was imported successfully.

#11 works.
Thanks, @xandermar!

I'm running into the same issue, but cannot find the user.role.[role].yml files. Where do I find these files?

@robbe03 those files are in your sites config storage path.

I had a similar issue as number #10 during a migration from D9 to D10.
I believe my client has removed a module or content type that had a permission that wasn't deleted as expected.

To fix it I've created a hook update with the following contents:

  $roleId = 'editor';

  $brokenPermissions = [
    'update lifetime content on assigned domains'
  ];
  
  $role = \Drupal::entityTypeManager()->getStorage('user_role')->load($roleId);
  foreach ($brokenPermissions as $permission) {
    $role->revokePermission($permission);
  }

  $role->save();

After running the update, saving a text format worked as expected.

I am also having this issue on a fresh install of 10.1.6 with Commerce plugin when I delete a Commerce Product (or child Variation) with Field Permissions. I am logged in admin account. There are no users on this site and not that much complexity as it is just a couple days into dev. Should be simple to reproduce.

This patch adds the missing dependency of used field storage.

@tobiasb thank you! Could you perhaps provide this as MR?
Is there any place in core where we can find a similar implementation or a documentation about that way?

Would be super nice to have this fixed, but I didn't see that kind of implementation before, which makes it hard to confirm, if it's the correct approach.

Here is the CR https://www.drupal.org/node/3055548 → . MR done.

Excellent @tobiasb! That looks like a perfect fix, thanks for the reference! I didn't know this before.

I'll give it a try asap, but code-wise I'd say clear +1!

Should we implement a test for this case to ensure it works as expected and won't break again? Typically, the module should have had such a test case already which should already fail (test-only) but it doesn't seem to exist yet.

@Anybody

I would say no. The module should only test his own API/functionality etc.

dependencies in perms are tested by core. ;-)

The patch #11 from this issue RuntimeException: Adding non-existent permissions to a role is not allowed 🐛 RuntimeException: Adding non-existent permissions to a role is not allowed Active fixed it for me, even that this is for drupal 11 core.

#6 led me down the right path and #8 led me to the correct file. I had a similar issue when trying to save permissions (and I can also confirm that #9 is true... can't save permissions with the stale permissions stuck in the config).

I had a Paragraph type that I had created a few weeks ago then recently deleted because I didn't need it any more. The permissions tied to that Paragraph type were still in the config. I'm assuming that patch that others have provided solves this issue? I haven't applied the patch yet though. I just edited the necessary .yml files manually (luckily I hadn't created all of my user roles yet so only had to edit 'config/sync/user.role.admin.yml').

My scenario (running D10.2.2):

1. Went to do a permissions audit on my site prior to launch
2. Checked through my admin permissions, checked boxes where appropriate
3. Saved
4. Encountered a big ugly Drupal error screen indicating the permissions. Error message looked like: "RuntimeException: Adding non-existent permissions to a role is not allowed."
5. Googled... found this thread
6. Located my config/sync/user.role.admin.yml file and removed the necessary permissions (just did a ctrl-F for those permissions that were in the big ugly Drupal error and deleted them, then saved the file)
7. Cleared Drupal cache
8. Tried to save the permissions again... got the error again
9. Did a 'drush cim' and accepted the changes
10. Did a 'drush cr' then checked the permissions again on the Admin role for other stuff I needed grant the Admin role
11. Saved successfully

I'm not advanced enough to know how to apply a patch but can go the manual route. Hopefully the patch alleviates the need to do it manually in the future

Thank you coupertrouper

After migration from D7 to D10 I had errors with permission for Text formats like this:
RuntimeException: Adding non-existent permissions to a role is not allowed. The incorrect permissions are "use text format 3". in Drupal\user\Entity\Role->calculateDependencies() (line 207 of /var/www/html/web/core/modules/user/src/Entity/Role.php).

Your post showed me the way.

I got similar type error while enable or disable module.

ERROR :

In Role.php line 207:

Adding non-existent permissions to a role is not allowed. The incorrect permissions are "create reusable blocks".

Some how the permission got broken. might be due to deletion of permission or overwrite.

So I have identify the possible module where the permission could be broken. Then I have created a custom permission file with the name of the broken permission "create reusable blocks".

docroot/modules/custom/my_custom_module/my_custom_module.permissions.yml

create reusable blocks:
title: 'create reusable blocks'
description: 'Permission for reusable block'

Next I have run the "composer install" command to build the broken permission 'create reusable blocks'.

Do not forget to run "drush cr" after build the permission.

Hope these might help you.

Just ran into this myself latest version of Drupal 10.2.6

It occured because a field I created (as a test) on user account views and set the view own permission for a role then later deleted the field. The field was a default core number field added to account settings at /admin/config/people/accounts/fields.
- I was under the impression if you delete a field any configuration and or permissions wherever they are used would be removed as well, but I guess that is not the case. Like others have listed here updating any permissions after the fact causes a Runtime Exception: Adding non-existent permission to a role is not allowed.

I'm adding this info to this thread for those that fall victim to this and DO NOT have a sites/default/files/config_.. directory containing the configuration file (user.role.[role].yml) - like me.

Go to: /admin/config/development/configuration/single/export

Select "Role" for Configuration type and in the Configuration name "the name of the affected role" for me it was "Authenticated user (authenticated)" - if the permission in question was applied to multiple roles, you will need to update each. If your not sure which role(s) are affected select each one then either user browser find in or hit ctrl + F and search for the field name that was listed in the error in the output area of the export where it says "Here is your configuration:"

When you find it, delete that line from the output then copy it and then click on the Import tab above and select Single Item tab.

For configuration type select "Role" like you did for the export, then paste what you copied where it says "Paste your configuration here *" and click the import button at the bottom and then confirm it.

That's it you're done, updating permissions will no longer produce the error unless there are other fields that have also been removed prior to removing their permissions.

Just also chiming in I ran into this trying to uninstall the older 2.0.2 version of the Group module from a 10.2.6 install. I had to recreate the offending/missing group types, then uncheck all but the default Admin allowed permissions, then I could remove the group types again and proceed without hitting additional errors.

In the 2.x branch, we need the field instance to be the requirement. Here's a patch for that behavior.

Ran into this with the address field, could not set permissions.
The patches did not work.

I saw the problem now in two different instances:

1) I had created a profile with fields
2) If I delete a single field, the config for the role still contains the permissions for that field, even though they should be deleted.
3) If I delete the WHOLE profile type, the config for the roles still contains all permissions from the deleted entity.

I think, this is a major bug, because it leaves the system with a WSOD.

Yes, for those who know how to work with configs, you can edit the configs. But even then, I learned, at times you have to be careful, and some sections need to be set to empty, that is { }.

So it is not trivial, and for sure, any site builder without that knowledge will get a system that no longer functions well. In essence, the module here breaks the site.

The real solution would have to somehow flush out the role configs whenever a field or entity-type is deleted.

I had tried the patch above, and it did not work for me.

I ran into the same issue. For me it happend after I deleted on fo the fields that was using field_permissions. Field was deleted from db, but permissions stayed un user.role.*.yml file. In effect, any other changes to the permissions of other fields, resulted in this error.

It looks like we need to make sure user.role.*.yml files are updated when entity or fields is deleted.

Manual fix from #11 worked fine for me