How to Fix SharePoint Online Troubleshooting Issues
Why SharePoint Online Troubleshooting Is Such a Headache
I've seen this exact situation on dozens of tenants: you open SharePoint Online, and something's just broken. Maybe it's a document library refusing to sync. Maybe you're getting a cryptic Access Denied error even though you set the permissions yourself five minutes ago. Maybe files won't upload, pages won't load, or the entire site collection is throwing a Sorry, this site hasn't been shared with you message to people who absolutely should have access.
Here's the hard truth , SharePoint Online is genuinely complex infrastructure. It's not a single app. It's a distributed cloud service layered on top of Microsoft 365, Azure Active Directory (now called Microsoft Entra ID), OneDrive, the Microsoft Graph API, and a permissions model that has roughly four hundred ways to go wrong. When something breaks, the error message you get is usually designed for the service, not for you.
The most common SharePoint Online troubleshooting scenarios I deal with fall into these buckets:
- Permissions and access errors , "Access Denied," "Sorry, this site hasn't been shared with you," or the infamous correlation ID screen
- Sync failures, OneDrive sync client stuck, files showing as "Upload failed," or the sync relationship completely broken
- Page and web part errors, Modern pages failing to render, web parts showing an error icon, or classic pages broken after a tenant migration
- Search not returning results, Files exist but don't appear in search, or search returns stale/incorrect data
- File upload and storage errors, 429 throttling responses, storage quota warnings, or "The file is locked for editing" messages that won't clear
- External sharing failures, Guest users can't accept invitations, sharing links expire unexpectedly, or the Sharing button is greyed out
I know this is frustrating, especially when your team is waiting on you to fix it so they can get back to work. The good news is that most of these issues have a clear, repeatable fix. Microsoft's own error messages rarely point you in the right direction, but the fix is almost always in the tenant admin center, a PowerShell command, or the Entra ID portal. Let me walk you through what actually works.
The Quick Fix, Try This First
Before you dive into admin centers and PowerShell sessions, do this. It resolves a shocking number of SharePoint Online troubleshooting calls I get:
Step 1: Clear your browser cache for the SharePoint domain. Open your browser (Edge or Chrome), press F12 to open DevTools, right-click the browser's Reload button, and select Empty Cache and Hard Reload. Then close DevTools and try again. SharePoint Online caches aggressively on the client side, and stale cache data causes a wide variety of weird permission and rendering issues.
Step 2: Try an InPrivate / Incognito window. Press Ctrl + Shift + N in Edge or Ctrl + Shift + P in Firefox. Navigate directly to your SharePoint site URL. If it works in a private window but not a normal one, the problem is a cached credential or browser extension interfering, not a SharePoint configuration issue.
Step 3: Sign out and back in to Microsoft 365. Go to portal.office.com, click your profile picture in the top right, select Sign out, then close all browser tabs completely and sign back in. Token expiration and stale Entra ID tokens are responsible for a lot of phantom access denied errors. This step forces a fresh token request.
Step 4: Check the Microsoft 365 Service Health dashboard. Go to admin.microsoft.com → Health → Service health. Look for any active incidents under SharePoint Online. I've had teams spend two hours troubleshooting something that was a Microsoft-side outage with a fix already in progress. Check this before you do anything else.
If none of those work, you're dealing with an actual configuration issue. That's where the step-by-step process below comes in.
1e9d3a1f-8b4c-4f2e-a7d3-9bc8e1f4a2c5), copy it immediately. You can use this in the Unified Audit Log to trace exactly what happened. Go to compliance.microsoft.com → Audit → filter by date and paste the correlation ID into the search. It often reveals the exact permission or policy that blocked the request.
Permission problems are the number one reason people end up troubleshooting SharePoint Online. The tricky part is that SharePoint has three separate permission layers that can all independently block access: site-level permissions, list/library permissions, and item-level permissions. On top of that, Entra ID group memberships feed into all of them.
Start at the site collection admin level. Navigate to your site, then go to the URL https://yourtenant.sharepoint.com/sites/yoursite/_layouts/15/user.aspx, this is the People and Groups page. Check what groups the user is actually in. If they're not there at all, that's your problem.
To add someone properly, go to Site Settings (gear icon → Site settings) → Site permissions → Grant permissions. Enter the user's email address, choose the permission level, and click Share. Don't use the Share site button from the top-right, it sends an invitation email but sometimes doesn't properly register in the permissions backend until the user clicks the link.
If the user shows up in the permissions list but still gets Access Denied, run this PowerShell check using the PnP module:
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive
Get-PnPSiteCollectionAdminThen verify their direct permissions on the specific library causing the problem:
$web = Get-PnPWeb
$list = Get-PnPList -Identity "Documents"
Get-PnPListPermissions -Identity $listIf permissions inheritance is broken at the library or item level, that's your culprit. You'll see it in the output as HasUniqueRoleAssignments : True. You can reset inheritance in the UI: go to the library → Library settings → Permissions for this document library → Delete unique permissions. After the user refreshes, they'll inherit from the parent site and the access should clear up immediately.
Sync issues are one of the most common SharePoint Online troubleshooting scenarios I see in enterprise environments. The OneDrive sync client (the cloud icon in your system tray) quietly fails to sync SharePoint document libraries, and users often don't notice until files are missing from their desktop or a colleague can't see recent changes.
First, check the sync status. Click the OneDrive cloud icon in the system tray (bottom right of your taskbar, you may need to click the ^ to expand). If you see a red X or a yellow warning triangle, hover over it to see the error message. Common codes you'll see include Error 0x80070185 (cloud file provider not running), Error 0x8007016A (cloud file callbacks already registered), and the general sync pending loop where nothing actually uploads.
The most reliable fix for stubborn sync problems is to reset the OneDrive client completely. Close OneDrive first (right-click the system tray icon → Quit OneDrive), then run this command in Run (Win + R):
%localappdata%\Microsoft\OneDrive\onedrive.exe /resetWait about 60 seconds. OneDrive will restart automatically. If it doesn't, launch it manually from Start. It'll go through a brief re-sync process. For most error codes, this completely resets the sync engine state and clears the problem.
If the reset doesn't work, check whether the file path is too long. SharePoint Online supports file names up to 400 characters, but the combined local path + file name on Windows is limited to 260 characters by default (the MAX_PATH limit). You'll get silent sync failures for files that exceed this. Enable long path support via Group Policy: Computer Configuration → Administrative Templates → System → Filesystem → Enable Win32 long paths → Enabled. Or run this in an elevated PowerShell session:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -ForceRestart the machine after applying this. Files in deep folder structures will start syncing again.
Modern SharePoint pages can fail to render for several different reasons, and the error icon on a web part is notoriously uninformative. You'll see a grey box with a warning icon, the message "Something went wrong," and sometimes a tiny details link that gives you a JavaScript stack trace. Not helpful on its own, but there are ways to dig further.
Start with the browser console. Press F12, click the Console tab, and reload the page. Look for red errors. Common ones include 401 Unauthorized on Graph API calls (token/permission issue), 404 on a web part script bundle (the app catalog version is stale or the app was removed), or CORS errors (a custom SPFx solution is calling an API that hasn't been added to the allowed origins list).
For a misbehaving built-in web part like News, Highlighted content, or Quick links, try appending ?maintenancemode=true to the page URL:
https://yourtenant.sharepoint.com/sites/yoursite/SitePages/YourPage.aspx?maintenancemode=trueThis loads the page in maintenance mode, showing each web part as a block you can remove individually. Delete the broken web part and re-add it fresh, this resolves issues caused by corrupted web part property bags more reliably than trying to edit the properties.
For custom SPFx solutions failing across the tenant, the fix is usually in the App Catalog. Go to SharePoint Admin Center (admin.microsoft.com → SharePoint) → More features → Apps → App Catalog. Find the app in Apps for SharePoint, check its deployment status, and if it shows as "Error" try retracting and re-deploying the solution package. If the package version hasn't changed, you may need to increment the version number in the solution manifest before re-uploading. SharePoint won't re-deploy a package at the same version number.
This is one of the more frustrating SharePoint Online troubleshooting scenarios because the files are clearly there, you can see them in the library, but search returns nothing. Or search worked fine last week and now suddenly it's showing results from months ago. What's going on?
SharePoint Online uses a continuous crawl system, but changes don't appear in search results instantaneously. The typical crawl-to-index latency is 15 minutes for content changes, but for brand new sites or after major structural changes (new site columns, content types added) it can take up to 24 hours for the managed properties to be fully indexed. If files are brand new, wait and try again before escalating.
If search has been broken for longer than 24 hours, first check whether the site is excluded from search. Go to Site Settings → Search and offline availability. Make sure Allow this site to appear in search results is set to Yes. This setting is enabled by default but sometimes gets flipped during site template deployments or scripted provisioning.
For library-level exclusion, go to Library Settings → Advanced settings and check the Search option, make sure it says Yes, allow items from this document library to appear in search results.
If content still isn't appearing after 24 hours and both settings are correct, you may need to manually request a re-index. Go to Site Settings → Search and offline availability → Reindex site → click Reindex site. For a specific library: Library Settings → Advanced settings → Reindex Document Library. This queues the content for the next full crawl, which typically runs within a few hours.
For search schema issues (custom managed properties not mapping correctly), check the Search Schema in the SharePoint Admin Center under More features → Search. Look for your crawled properties and verify they're mapped to a managed property with the Searchable, Queryable, and Retrievable checkboxes enabled.
External sharing in SharePoint Online is controlled at three levels: the Entra ID tenant level, the SharePoint tenant level, and the individual site level. If external sharing is blocked at any of these levels, the more permissive settings below don't matter, the most restrictive setting always wins.
Start in the SharePoint Admin Center at admin.microsoft.com/sharepoint. Go to Policies → Sharing. Under External sharing, you'll see a slider with four options: Anyone, New and existing guests, Existing guests only, and Only people in your organization. Your tenant-level setting must be at least as permissive as what you want sites to allow. If it's set to "Only people in your organization," no site can share externally regardless of its own settings.
For a specific site, go to Sites → Active sites in the Admin Center, click the site name, then click Policies → Edit under External sharing. Set it appropriately.
If the sharing settings look correct but guests still can't accept invitations, the problem is usually in Entra ID. Go to entra.microsoft.com → External Identities → External collaboration settings. Check that Guest user access is not set to "Guest users have no access to properties and memberships of directory objects", that setting breaks SharePoint guest access entirely because guests can't resolve group memberships.
Also check the Collaboration restrictions section. If specific domains are blocked or if only specific domains are allowed, invitations to domains outside that list will silently fail. The guest receives the invitation email, clicks Accept, and gets redirected to an error page with no explanation. Add the guest's domain to the allowed list if you're using an allowlist, or remove it from the blocklist.
For guests who were previously working and suddenly lost access, run this PowerShell to check their Entra ID guest account status:
Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -Filter "userType eq 'Guest' and mail eq 'guestuser@external.com'" |
Select-Object DisplayName, AccountEnabled, SignInActivityIf AccountEnabled is False, the account was disabled by an Entra ID lifecycle policy or an admin. Re-enable it in Entra ID → Users → find the guest → click Enable.
Advanced SharePoint Online Troubleshooting
When the standard fixes don't work, it's time to go deeper. These techniques are what I use when a SharePoint Online troubleshooting issue has been escalated past the first tier and we need to find the actual root cause rather than just clear the symptom.
Event Viewer and ULS Log Analysis
For on-premises SharePoint you'd use ULS logs, but for SharePoint Online the equivalent is the Unified Audit Log in the Microsoft Purview compliance portal. Go to compliance.microsoft.com → Audit. Set a date range, filter by workload = SharePoint, and enter the affected user's email. Look for events with AccessDenied, SharingInheritanceBroken, or PermissionLevelModified in the Operation field. This tells you exactly what changed and when, which is invaluable for proving whether a permission was revoked deliberately or by a process running in the background.
Conditional Access Policy Conflicts
One increasingly common cause of SharePoint Online access failures is a Conditional Access policy in Entra ID that's blocking access from certain devices, locations, or client applications. If a user can access SharePoint from their corporate laptop but not their home computer, Conditional Access is almost certainly the issue. In Entra ID → Sign-in logs, find a failed sign-in attempt for the affected user and look at the Conditional Access tab in the sign-in details. It will tell you exactly which policy applied and what the result was (Success, Failure, Not Applied). The policy name is clickable and takes you directly to the Conditional Access policy to review or modify it.
Tenant-Level Throttling and 429 Errors
If you're running PowerShell scripts or custom SPFx solutions against SharePoint Online and getting intermittent failures, you're likely hitting tenant throttling. SharePoint Online enforces resource unit (RU) limits per tenant per minute. When you exceed them, requests return HTTP 429 with a Retry-After header specifying how many seconds to wait. The fix is to implement exponential backoff in your code and, for long-running scripts, add a Start-Sleep -Seconds 1 between each PnP call. For the PnP PowerShell module specifically, you can add the -RetryCount 3 and -RetryWait 10 parameters to most cmdlets to handle this automatically.
Site Collection Administrator Access Recovery
If you've been locked out of a site collection entirely, no site collection admins exist or they've been removed, you can recover access through the SharePoint Admin Center. Go to Sites → Active sites, find the site, select it, and click Membership → Site admins → Add site admins. Add yourself or the correct admin. This works even if you have no permissions on the site itself, as long as you're a SharePoint Administrator or Global Administrator in the tenant.
Checking for Overshared Content with PowerShell
For security audits or when tracking down why the wrong people have access, this script lists all unique permission assignments across a site collection:
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive
$lists = Get-PnPList
foreach ($list in $lists) {
if ($list.HasUniqueRoleAssignments) {
Write-Host "Library: $($list.Title) has unique permissions"
$items = Get-PnPListItem -List $list -Fields "FileLeafRef"
foreach ($item in $items) {
if ($item.HasUniqueRoleAssignments) {
Write-Host " Item: $($item['FileLeafRef']) has unique permissions"
}
}
}
}If you've worked through all of the above and the problem persists, particularly if you're seeing consistent errors in the Unified Audit Log that reference internal service operations, or if entire site collections are inaccessible for all users including admins, it's time to raise a support ticket. I'd also escalate immediately if you're seeing data loss scenarios (files deleted with no audit trail, versioning history missing) or if a SharePoint migration has left a site collection in an inconsistent state. When you contact Microsoft Support, have your tenant ID, the affected site URL, the correlation ID from the error screen, and the Unified Audit Log export ready. This cuts the diagnostic time dramatically.
Prevention & Best Practices for SharePoint Online
Most SharePoint Online troubleshooting calls I handle are repeat occurrences of something that already happened once before. The good news: a handful of proactive habits eliminates the majority of recurring issues.
Use Microsoft 365 Groups or Entra ID security groups instead of direct user permissions. This is the single most impactful change you can make. When you grant access to a group rather than individual users, you never have to hunt through 400 unique permissions entries wondering why someone has access to something they shouldn't. You just check group membership. It also makes offboarding clean, remove a user from the group and their access disappears everywhere simultaneously, no orphaned permissions left behind.
Establish a clear external sharing policy and communicate it. Most external sharing problems I see happen because nobody told site owners what the rules are. Document your tenant's sharing policy, which domains are allowed, whether "Anyone" links are permitted, maximum link expiration times, and share it with every site owner. In the SharePoint Admin Center, set a default link expiration for Anyone links under Policies → Sharing → set These links must expire within this many days to something reasonable like 30 days. This prevents forgotten sharing links from becoming a security problem six months from now.
Monitor your Service Health dashboard regularly. Set up email notifications for SharePoint Online in the Microsoft 365 Admin Center under Health → Service health → Preferences. You'll get an email as soon as Microsoft detects a service issue, which saves you from spending an hour troubleshooting what's actually a Microsoft-side outage.
Keep your OneDrive sync client updated. A huge number of sync errors I've fixed were simply due to an outdated OneDrive client version. OneDrive auto-updates by default, but in managed environments IT sometimes blocks automatic updates. Make sure your deployment is on a current release (check About OneDrive in the system tray menu and compare to the current release notes at the Microsoft OneDrive release notes page).
- Run the Microsoft 365 Connectivity Test at
connectivity.office.commonthly to catch network-level issues before they affect users - Enable versioning on all document libraries (at least 50 major versions), this is your best protection against accidental deletions and ransomware
- Review the SharePoint Access Requests list at
/sites/yoursite/_layouts/15/ManageRequests.aspxweekly to catch access gaps before users complain - Set a Site Collection Storage quota warning alert in the SharePoint Admin Center, running out of storage causes silent upload failures that are very hard to diagnose after the fact
Frequently Asked Questions
Why do I keep getting "Access Denied" in SharePoint even though I have Full Control?
This is almost always caused by broken permissions inheritance. A specific library, folder, or item has had unique permissions applied that override the site-level Full Control you were granted. Navigate to the specific item or library causing the problem, go to its permission settings, and look for a yellow banner that says "This list has unique permissions." Click Delete unique permissions to restore inheritance from the parent site. If you're getting Access Denied on the site itself despite being listed as a site collection admin, try adding yourself again through the SharePoint Admin Center, sometimes the admin assignment doesn't propagate correctly on the first attempt and a second add resolves it.
SharePoint Online search isn't finding files I uploaded today, is it broken?
Not necessarily, it's probably just the crawl delay. SharePoint Online uses a continuous crawl, but new content can take anywhere from 15 minutes to several hours to appear in search results depending on tenant load. If a file has been there for more than 24 hours and still doesn't appear, check that the library isn't excluded from search (Library Settings → Advanced settings → Search → Yes). Also verify the file isn't checked out, checked-out files are not crawled. If it's been more than 24 hours, trigger a manual re-index from Site Settings → Search and offline availability → Reindex site.
My SharePoint site says "Sorry, this site hasn't been shared with you" but I'm an admin, why?
This error appears when your user account isn't in the site's site collection admins list, even if you're a Global Admin or SharePoint Admin in the tenant. Being a tenant-level admin doesn't automatically give you access to every site collection, this is by design for privacy reasons. Fix it by going to the SharePoint Admin Center → Sites → Active sites → select the site → Membership → Site admins → Add yourself. Once added, refresh the page and you'll have access. You can also use PowerShell: Set-SPOUser -Site "https://yourtenant.sharepoint.com/sites/yoursite" -LoginName "youremail@domain.com" -IsSiteCollectionAdmin $true.
How do I fix SharePoint Online sync showing "Upload failed" for certain files?
The most common reason specific files fail to upload while others sync fine is an invalid character or reserved word in the file name. SharePoint Online doesn't allow file names that contain these characters: ~ " # % & * : < > ? / \ { | }. It also blocks names like "CON", "PRN", "AUX", "NUL", "COM0" through "COM9", and "LPT0" through "LPT9", these are Windows reserved names. File names beginning or ending with a space or period also fail. Rename the file to remove the problematic character and sync will resume. If the file name looks clean, check whether the combined path length exceeds 400 characters, shorten the folder structure.
External users are getting an error when they click the SharePoint sharing link, how do I fix this?
The most likely cause is that the sharing link has expired or the recipient's domain is blocked at the tenant or site level. Check the SharePoint Admin Center → Policies → Sharing and look at your link expiration settings and allowed domains list. If the domain is blocked, add it to the allowed domains list or switch from an allowlist to a blocklist model. If the link hasn't expired, try revoking the link and creating a new one with a generous expiration window. Also check Entra ID External collaboration settings, if guests from the recipient's domain are blocked at the directory level, no SharePoint sharing will work for them regardless of link settings.
Can I recover a SharePoint site collection that was accidentally deleted?
Yes, within 93 days of deletion. Go to the SharePoint Admin Center → Sites → Deleted sites. You'll see all recently deleted site collections listed there. Select the one you need and click Restore. The site is restored with all its content, permissions, and settings intact. If it's been more than 93 days, the site is permanently deleted and the only option is to restore from a backup, which requires you to have been using Microsoft 365 Backup (the paid add-on) or a third-party backup solution like Veeam or AvePoint. This is why enabling Microsoft 365 Backup for critical SharePoint sites is worth every penny.