Forum Discussion
OneDrive/SharePoint permission problem
Hello,
the problem is that we have a user which wants to share file(s) with another user. If he shares the file and he gives him permissions for read and write the he is still not allowed to open it, even if he askes for permissions an those will be granted it still does not work. This works (or does not work) with several files, but not with all.
If those files ares shared with other users it works instantly.
We have another user with this problems, the only thing they have in common is, that both were deactivated over a period of I think 5-6 months or even longer.
It is not with every file, and it does not matter if those files were uploaded in SharePoint or OneDrive and it does not really matter who uploaded it.
If I e.g. downloads a file which does NOT work and I upload it again it works.
I am not sure if I described it properly, but this problem only appears for 2 users which were disabled and unlicensed for a longer period of time.
Is the only way to fix this to delete the account and create a new one, so that a whole new User ID is created and nothing is related to the old user or is there a proper way to handle it, because to delete the account and create a new one is more or less the last thing I want to do.
Thanks in advance
3 Replies
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.
This issue is most likely the result of stale or orphaned permissions associated with the users’ previous Azure AD object IDs during their deactivation period. It is not necessary to delete and recreate the accounts. A more effective approach is to re‑establish permissions by using tools such as Check Permissions, removing and re‑adding the users to the relevant site or library, or re‑sharing the affected files so that they inherit updated permissions tied to the current user identity.
Troubleshooting Permission Issues in SharePoint Online (2026)
This looks like a classic SharePoint issue caused by a broken user profile after the account was disabled for a long time. Permissions are technically there, but SharePoint links them to a different internal ID, so access fails for some files. The fact that re-uploading the file fixes it pretty much confirms this. Before deleting the account, try removing and re-adding permissions (preferably via a group) or moving the files to a new library - that often fixes it.
