DEV Community

Cover image for Real Case: OneDrive/SharePoint Access Issue Finally Solved
Ivaj O'Franc
Ivaj O'Franc

Posted on • Edited on • Originally published at dev.to

Real Case: OneDrive/SharePoint Access Issue Finally Solved

#it #onedrive #sharepoint #troubleshooting 
id: 2749935
title: "Real Case: OneDrive/SharePoint Access Issue Finally Solved"
published: true
tags: ["it", "onedrive", "sharepoint", "troubleshooting"]
series: I Fixed It and I Don't Know How
description: "An access issue that couldn’t be fixed by resharing files. The root cause was hidden in SharePoint's UserInfo list. The solution? A little-known Microsoft 365 diagnostic tool."
canonical_url: "https://dev.to/ivajofranc/real-case-onedrivesharepoint-access-issue-finally-solved-19bd"
cover_image: "https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F15aaniatkf8d44btvk95.png"
Enter fullscreen mode Exit fullscreen mode

Real Case: OneDrive/SharePoint Access Issue Finally Solved

🇪🇸 Lee también este post en español

🎯 Quick Summary

A user couldn’t access shared files in OneDrive/SharePoint.

Classic message: “Request access to view the file”.

Newly recreated account, permissions reshared — nothing worked.

Spoiler: it wasn’t Azure AD’s fault.

❌ What We Tried (And Didn’t Work)

  1. Checked the user in Azure AD

    Account was fine, correct ObjectId in place.

  2. Looked for deleted objects in Azure AD

    Tried finding the old account, but it had already been purged.

  3. Reshared files from scratch

    Removed old permissions, shared again, tested in incognito mode...

    Same error. Seriously?

  4. Created fresh test files

    New Excel file shared with the user only.

    Still no access. Are we making this up?

🧠 Technical Diagnosis (The Real Deal)

The issue was in SharePoint Online, in a hidden list called UserInfo within the OneDrive site of the file owner.

That list kept a reference to the old ObjectId (now deleted), so SharePoint continued to validate against a non-existent identity.

Result: file shared, access denied.

✅ The Magic Fix

We ran the official Microsoft 365 diagnostic called “Site User ID Mismatch” from the Admin Center:

  • Detected the identity conflict in the UserInfo list.
  • Removed obsolete references.
  • Re-synced permissions using the correct ObjectId.

🔗 Helpful links for more info:

🔄 Final Result

  • User received a new invite.
  • Can now open files without requesting access.
  • Tested in multiple browsers and incognito — all good.
  • Issue fixed for both old and new files.

📝 Conclusion

When you delete and recreate user accounts, SharePoint may keep outdated metadata that blocks access.

The official Microsoft tool safely cleans up this inconsistency without manual headaches.

💡 Recommendations Going Forward

  • If access issues arise after recreating users, run the “Site User ID Mismatch” diagnostic.
  • Clear the UserInfo list during major migrations or reprovisioning.
  • Avoid reusing deleted accounts within 30 days if possible.

This post is part of “I Fixed It and I Don't Know How”: real-world IT fixes, no fluff, no tricks hidden.

Top comments (0)