OneDrive/SharePoint permission problem

This issue is typically caused by a User ID Mismatch in the SharePoint/OneDrive User Information List (UIL). When users are deactivated for long periods, SharePoint may retain a cached profile or internal ID that no longer matches their active account's current ID. This explains why re-uploading (creating a fresh file with new metadata) works, but old permissions fail. 

You do not need to delete and recreate the accounts. Instead, you must remove the problematic user's "ghost" profile from the specific site collections where access is failing. 

Step 1: Use the Microsoft Diagnostic Tool (Admin Only) 

Microsoft provides a specific diagnostic to fix this without manual intervention. 

Sign in to the Microsoft 365 Admin Center.

Select the Help & Support (?) icon and search for "Diag: Site User ID Mismatch".

Enter the UPN (email) of the affected user and the URL of the site or OneDrive where access is failing.

Run the test. If a mismatch is found, it will offer to remove the old ID. 

Step 2: Manual Removal via the "MembershipGroupID=0" Trick 

If you cannot use the diagnostic, manually remove the user from the site's hidden User Information List to force a refresh. 

Navigate to the SharePoint or OneDrive site where the files are located.

Append the following to the end of the site URL:

/_layouts/15/people.aspx?MembershipGroupID=0

Example: yourtenant.sharepoint.com

On the page that opens, locate the affected user in the list.

Select the user, click Actions, and choose Delete User from site collection.

Wait a few minutes, then re-share the file with the user. This creates a new, correct entry in the site's user database. 

Step 3: Refresh the OneDrive User Profile 

For problems specifically within the user's own OneDrive or when others share with them:

Ensure they have a valid, active license assigned. Changes can take up to 24–48 hours to fully propagate for accounts that were archived or inactive for long periods.

If they cannot access their own OneDrive, an admin should verify if the URL has a suffix (e.g., user_domain_com1). If so, the Site User Mismatch diagnostic (Step 1) is required to reconnect them to the original site. 

Why this happens

SharePoint stores user data (UPN and internal ID) in its own local database for every site collection. When a user is rehired or reactivated, the new account might have a different internal ID even if the email (UPN) is identical. Old files still "look" for the original ID, causing an "Access Denied" error even when permissions appear correct in the UI.