Getting 'The feature has been disabled. Please contact your admin to get it enabled' when trying to delete a permission

Hi @Narinder Paul,

As this is primarily a user-to-user support forum, I am not part of Microsoft's internal engineering team. Therefore, I can only review the publicly available Microsoft documentation and share my understanding based on the documented behavior. I hope the following information may be helpful as a reference.

Based on the documented requirements, this does not appear to be caused simply by insufficient Microsoft Graph application permissions. The delete-permission API supports Files.ReadWrite.All or Sites.ReadWrite.All for application access. If Files.ReadWrite.All has been granted admin consent and is present in the access token’s roles claim, no additional permission beyond the documented requirements should be necessary.

First, retrieve the current permission:

GET /drives/{drive-id}/items/{item-id}/permissions/{permission-id}

Only permissions granted directly on the file or folder can be deleted. An inherited permission must be removed from the parent resource where it was originally granted. However, OneDrive for Business and SharePoint document libraries do not return the inheritedFrom property, so inheritance may also need to be verified from the parent item or through Manage access.

Also check whether the permission contains a link facet. If it represents a Specific people sharing link, deleting that permission deletes the sharing link and may remove access for all recipients associated with it, not only the external user. Removing only one recipient from a user-scoped sharing link is documented through the revokeGrants API, but that API is currently available only under the Microsoft Graph /beta endpoint and is not supported for production use.

The transition from legacy SharePoint OTP to Microsoft Entra B2B is not documented as requiring additional Graph permissions for deleting a file permission. Microsoft also states that enabling B2B integration does not itself change the existing SharePoint or OneDrive sharing settings. Therefore, this transition should not be considered the confirmed cause of the 403 response without further evidence.

The error message alone also does not confirm that an external-sharing policy is blocking deletion. Microsoft’s public documentation does not map this specific 403 notAllowed response to a particular SharePoint or Entra sharing setting. It may instead be related to the permission’s type, inheritance, sharing-link structure, or another server-side validation.

If the permission is direct, the permission ID is current, and the token contains Files.ReadWrite.All, the documented request should return 204 No Content:

DELETE /drives/{drive-id}/items/{item-id}/permissions/{permission-id}

If it still returns 403 notAllowed, especially when the same access can be removed through Manage access, the exact backend cause cannot be determined from the public documentation. In that case, open a Microsoft support request and provide the sanitized request and response, request-id, client-request-id, UTC timestamp, and the permission object returned by the GET request so Microsoft can trace the server-side restriction.

For reference, these are some of the documents I reviewed:

• Delete a sharing permission from a file or folder
• SharePoint and OneDrive integration with Microsoft Entra B2B
• Permission resource type
• permission: revokeGrants

I hope this provides some useful information and possible directions for your investigation. Thank you for taking the time to provide the detailed background.

If the answer is helpful, please kindly click "Yes" button below. If you have extra questions about this answer, please click "Comment".    

Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.