Troubleshooting SharePoint "Sorry, You Don't Have Access"

Few things in SharePoint are more maddening than seeing “Sorry, you don’t have access” when you know you’ve granted the right permissions. You’ve checked the permissions page. The user is listed. The permission level says Read or Edit. And yet - Access Denied.

This guide documents every cause I’ve encountered, organized as a systematic diagnostic checklist you can work through from the most common to the most obscure. Each section includes the diagnostic steps, the fix, and an anecdotal story from the field to help you recognize the symptoms faster.

Check 1: Draft Item Security and Minor Versions

Likelihood: Very High | Difficulty to Diagnose: Moderate

This is the single most common cause of phantom Access Denied errors in SharePoint, and it is the one most frequently missed - even by experienced administrators. The file exists, the permissions are correct, and yet the user cannot see it.

How It Works

SharePoint document libraries can be configured to use major and minor versioning. Major versions are published versions (1.0, 2.0, 3.0) visible to anyone with Read access. Minor versions are drafts (0.1, 0.2, 1.1, 1.2) and their visibility is controlled by a library setting called Draft Item Security.

Draft Item Security has three options: “Any user who can read items,” “Only users who can edit items,” and “Only users who can approve items (and the author of the item).” When set to the second or third option, users with only Read permission cannot see any file that has never been published as a major version.

The critical detail: if a file has only ever existed as a minor version (for example, version 0.1 through 0.15 with no major version ever published), then Read-only users will see nothing. To them, the file does not exist. If they try the direct URL, they get Access Denied.

There is a related catch: if the library also has Require content approval for submitted items enabled (in Library Settings → Versioning Settings), then even a published major version (1.0) will not be visible to Read-only users until it is explicitly approved. The file’s approval status remains “Pending” after publishing, and only users who can approve items (or the author) can see it. The fix is the same - either approve the item or disable the content approval requirement if it is not needed.

How to Diagnose

• Step 1: Check the file’s version number. If it’s something like 0.1, 0.5, or 0.15, it is a draft. It has never been published.
• Step 2: Go to Library Settings → Versioning Settings. Look at the Draft Item Security option.
• Step 3: If Draft Item Security is set to “Only users who can edit items” and the user only has Read, that’s your answer.

How to Fix

• Option A: Publish the file as a major version. Right-click → Version History → Publish a Major Version. The file becomes version 1.0 and is immediately visible to Read users.
• Option B: Change Draft Item Security to “Any user who can read items.” Be aware this affects the entire library.

From the Field: The Budget Tracker That Nobody Could Open A finance team shared a budget tracking spreadsheet with several department heads, granting them Read access. Every single one of them reported Access Denied. The site owner spent two hours verifying permissions, checking Azure AD, and even re-creating the sharing links. The file had been uploaded and edited over the course of three weeks - it was at version 0.15. Nobody had ever clicked Publish. Once the file was published as version 1.0, every department head could open it instantly. Two hours of troubleshooting for a single click.

Check 2: Sharing Link Token Scope

Likelihood: High | Difficulty to Diagnose: Easy

SharePoint sharing links are not just URLs - they contain encoded access tokens with a specific audience. If the link was generated with the wrong scope, the user will be denied even if they have direct permissions on the file.

How It Works

When you click Share in SharePoint and generate a link, you choose an audience: “Anyone with the link,” “People in your organization,” “People with existing access,” or “Specific people.” This choice is baked into the link’s token. When a user clicks the link, SharePoint validates the token first, before checking item-level permissions. If the token rejects the user, they get Access Denied.

The telltale sign: the URL contains parameters like ?d=w... and &e=... - these are the token. A direct URL to the file (without those parameters) bypasses the token entirely and relies only on item-level permissions.

How to Diagnose

• Step 1: Look at the URL being shared. Does it contain ?d= and &e= parameters? If so, it’s a sharing link with a token.
• Step 2: Try accessing the file using the direct URL (without the sharing parameters). If the direct URL works but the sharing link doesn’t, the token scope is the problem.
• Step 3: Click Manage Access on the file and review the sharing links. Check which audience each link was created for.

How to Fix

Re-share the file using the Share button and select “Specific people,” then add the user’s email address. This generates a new link token scoped to them. Alternatively, send the direct file URL instead.

From the Field: The Link That Worked for Everyone Except One Person A project manager shared a link with five vendors. Four could access the file; one could not. The manager had generated the link with “Specific people” and entered four email addresses, forgetting the fifth. Rather than checking the link’s audience, the team spent 45 minutes checking Azure AD guest accounts, browser settings, and Conditional Access. When someone finally checked Manage Access on the file, the fifth vendor’s email was simply not included in the sharing link. A new share fixed it in 10 seconds.

Check 3: Broken Permission Inheritance on Parent Folders

Likelihood: High | Difficulty to Diagnose: Tedious

When you grant permission on a file buried deep in a folder structure, SharePoint automatically grants Limited Access on each parent folder so the user can traverse the path. But if any parent folder has had its inheritance broken, this chain can be disrupted.

How It Works

Consider a file at: Shared Documents → Finance → External Shared → Fleet → 2026 → Budget.xlsx. The user needs at least Limited Access on Shared Documents, Finance, External Shared, Fleet, and 2026 to reach the file. If any one of those folders had its permission inheritance broken and the Limited Access entry was not propagated, the user hits a wall at that exact point in the chain.

How to Diagnose

This one is tedious but straightforward. Starting from the document library, check permissions at every folder in the path. For each folder, open Shared With or Manage Access and verify the user has at least Limited Access. The folder where they disappear from the permissions list is your problem.

How to Fix

Either re-share the file (which should recreate the Limited Access chain) or manually grant Limited Access on the offending folder. Better yet, if possible, avoid breaking inheritance on intermediate folders.

From the Field: The Six-Folder-Deep Scavenger Hunt A colleague called me after spending an entire afternoon on an access issue. They’d verified permissions on the file, verified the site-level permissions, checked Azure AD, and even called Microsoft support. Nobody thought to check the individual folders. Turns out someone had broken inheritance on the third folder in a six-folder chain to restrict access to a subfolder for a different project. When they did that, the Limited Access entry for several users was wiped out at that level. It took five minutes to find once we started checking each folder systematically.

Check 4: Limited-Access User Permission Lockdown Mode

Likelihood: Moderate | Difficulty to Diagnose: Easy (once you know to check)

This is a site collection feature with a long name and significant consequences. When activated, it restricts what users with Limited Access can do, including their ability to traverse the site hierarchy to reach shared items.

How It Works

The “Limited-access user permission lockdown mode” is a site collection feature designed to secure published sites. When enabled, users with the Limited Access permission level are prevented from accessing application pages, forms, and other site-level resources. This is useful for public-facing sites but can cause unexpected Access Denied errors on collaboration sites where users are granted access to individual files or folders.

The key impact: when this feature is active and you share a specific folder with a user, they may not be able to reach it because the Limited Access traversal is blocked.

How to Diagnose

Navigate to Site Settings → Site Collection Administration → Site Collection Features. Look for “Limited-access user permission lockdown mode.” If it shows as Active, this may be your culprit.

How to Fix

Deactivate the feature if your site does not require it. Be aware that the SharePoint Server Publishing Infrastructure feature depends on lockdown mode. If you have publishing enabled, deactivating lockdown mode may affect publishing functionality.

From the Field: The Publishing Feature That Locked Everyone Out A client had activated the Publishing Infrastructure feature on a team site for some page layout capabilities. Unknown to them, this automatically enabled lockdown mode. Months later, when they started sharing individual folders with external consultants, every consultant got Access Denied. The client was convinced it was an Azure AD problem and spent a week going back and forth with their identity team before someone stumbled onto the site collection features page.

Check 5: User Identity and Session Issues

Likelihood: Moderate | Difficulty to Diagnose: Easy

Sometimes the problem has nothing to do with SharePoint configuration. The user is simply signed into the wrong account.

How It Works

Modern browsers maintain multiple Microsoft 365 sessions. A user might be signed into their personal Microsoft account, a different organizational account, or a stale cached session. When they click a SharePoint link, the browser sends the credentials of whatever account is currently active - which may not be the account that has permission.

How to Diagnose and Fix

• Step 1: Ask the user to open an InPrivate (Edge) or Incognito (Chrome) browser window.
• Step 2: Navigate to the SharePoint URL.
• Step 3: Sign in explicitly with the correct account.

If this works, the issue is a cached session in their regular browser. Clearing browser cookies for microsoft.com and sharepoint.com domains usually resolves it.

From the Field: Two Accounts, One Browser An employee had both a work account (john@company.com) and a contractor account from a previous engagement (john.doe@othercompany.com). Their browser always defaulted to the contractor account. Every time they clicked a SharePoint link, it failed. They’d been requesting access for weeks, and the site owner kept approving it for john@company.com, not realizing the browser was sending john.doe@othercompany.com. An InPrivate window solved it immediately.

Check 6: Customized Permission Level Definitions

Likelihood: Low | Difficulty to Diagnose: Moderate

SharePoint’s built-in permission levels (Read, Edit, Contribute, Full Control) are made up of individual base permissions. If someone has customized a permission level and removed a critical base permission, users assigned that level may be blocked from specific actions.

How It Works

The Read permission level, by default, includes: View Items, Open Items, View Versions, Create Alerts, View Application Pages, Use Self-Service Site Creation, View Pages, Browse User Information, Use Remote Interfaces, Use Client Integration Features, and Open. If any of these are removed - particularly Open, Open Items, or View Pages - users may get Access Denied on files they should be able to see.

How to Diagnose

Go to Site Settings → Site Permissions → Permission Levels → Read. Verify that all expected base permissions are checked. Compare against the Edit permission level if Edit works but Read doesn’t - the difference will reveal the missing permission.

How to Fix

Restore the missing base permission, or create a new custom permission level with the correct set of base permissions.

From the Field: The Overzealous Security Audit After a security audit, an IT team decided to “tighten” permissions by removing “Use Remote Interfaces” from the Read permission level on several sites. This immediately broke the mobile SharePoint app and OneDrive sync for every Read user on those sites. The connection between the obscure-sounding base permission and the mobile app wasn’t obvious to anyone, and it took three days and a Microsoft support ticket to trace it back to that one checkbox.

Check 7: Guest and External User Account Status

Likelihood: Moderate (for external sharing) | Difficulty to Diagnose: Easy

When sharing with users outside your organization, there is an additional layer: the guest account in Azure Active Directory. Even if SharePoint permissions are perfect, a problem with the guest account will prevent access.

Common Issues

• Invitation not accepted: The guest user received the invitation email but never clicked the link to accept. Their account exists in Azure AD but is in a “PendingAcceptance” state.
• Expired invitation: The invitation link has expired. A new invitation must be sent.
• Stale or duplicate account: The guest user was previously invited with a different email address, creating a duplicate account. SharePoint permissions reference one account; the user signs in with the other.
• External sharing disabled: Sharing may be enabled at the tenant level but disabled for this specific site collection.

How to Diagnose

Check Azure AD → Users → Guest users. Search for the external user’s email. Verify the invitation status is “Accepted” and the account is active. Also verify that the email on the Azure AD guest account matches the email used in SharePoint’s permission grant.

From the Field: The Typo Nobody Caught A site owner invited an external partner by typing their email as testIT@dprs.ca instead of testIT@drps.ca - transposing two letters in the domain. SharePoint happily created a guest account for the wrong email and granted it Read access. The real user, signing in with the correct email, had no access. The permissions page showed the display name correctly, so nobody noticed the typo until someone clicked on the user entry and compared the underlying email address.

Check 8: Azure AD Conditional Access Policies

Likelihood: Low to Moderate | Difficulty to Diagnose: Difficult

Conditional Access policies are enforced by Azure AD before the user even reaches SharePoint. These policies can block access based on device compliance, IP location, MFA status, risk level, or client application type.

How It Works

When a user authenticates to access SharePoint, Azure AD evaluates all applicable Conditional Access policies. If any policy’s conditions are met and the grant controls require something the user cannot satisfy (like a compliant device or MFA), the access is blocked. The error message may appear as a SharePoint Access Denied rather than clearly indicating a Conditional Access block.

How to Diagnose

Check the Azure AD Sign-in Logs for the affected user. Filter by the SharePoint Online application. Failed sign-ins will show the Conditional Access policy that blocked access and the specific condition that was not met. This is the definitive way to confirm or rule out Conditional Access.

How to Fix

Work with your Azure AD administrator to either adjust the Conditional Access policy, ensure the user meets the policy’s requirements (install the Company Portal, complete MFA enrollment, etc.), or create an exclusion for the specific use case.

From the Field: The New Laptop A director got a new laptop and immediately lost access to several SharePoint sites. The old laptop had been enrolled in Intune and was compliant; the new one had not been enrolled yet. A Conditional Access policy required compliant devices for SharePoint access. The error message from SharePoint said nothing about device compliance - it simply said Access Denied. The director’s IT support team spent hours checking SharePoint permissions before someone thought to check the Azure AD sign-in logs.

Check 9: Web Client vs. Desktop Client Authentication

Likelihood: Moderate | Difficulty to Diagnose: Easy (once aware)

SharePoint URLs without any parameters will attempt to open in the desktop Office client by default. The desktop client uses a different authentication flow than the browser, and in some configurations, it is stricter about permissions on parent containers.

How It Works

When a user clicks a direct link to an Excel, Word, or PowerPoint file, SharePoint may hand off to the desktop Office application. The desktop client authenticates independently using its own token cache and may require broader access (more than just Limited Access on parent folders) to successfully negotiate the file download. The browser-based Office Online client, by contrast, handles the same permission chain more gracefully.

How to Diagnose

Append ?web=1 to the file URL. This forces the file to open in the browser. If the file opens successfully with ?web=1 but fails without it, the desktop client’s authentication flow is the issue.

How to Fix

• Quick fix: Share the link with ?web=1 appended so the file always opens in the browser.
• Proper fix: Grant the user Read (not just Limited Access) on the document library or a parent folder high enough in the chain to satisfy the desktop client’s requirements.

From the Field: Works in Browser, Dies on Desktop A user reported they could open a shared Excel file on their phone and on their home computer’s browser but not on their work desktop. The phone and home computer were using Excel Online; the work desktop was launching the installed Excel app. The installed app needed a stronger permission chain than what Limited Access on parent folders provided. Adding ?web=1 to the URL was the interim fix; granting Read at the library level was the permanent one.

Bonus: When Multiple Issues Overlap

In real-world troubleshooting, you will occasionally encounter situations where more than one of these issues exists simultaneously. This is especially common in mature SharePoint environments where multiple administrators have made changes over time.

The diagnostic approach remains the same: work through the checklist systematically, from top to bottom. Do not stop at the first issue you find - fix it, test, and if the problem persists, continue down the list. We have seen cases where fixing the sharing link scope revealed a hidden draft item security problem underneath, or where resolving a lockdown mode issue exposed a broken inheritance chain that had been masked by the broader lockdown.

From the Field: The Triple Fault In one memorable case, a SharePoint site had three simultaneous issues: lockdown mode was active (from a long-forgotten publishing feature activation), one parent folder had broken inheritance, and the file was a draft version. The site owner fixed each issue one at a time, testing between each fix. After disabling lockdown mode: still broken. After fixing the folder inheritance: still broken. After publishing the file as version 1.0: it finally worked. Any single fix in isolation would have appeared to fail, which could easily have led someone to conclude it wasn’t the right cause. Systematic diagnosis was the only way through.

Final Thoughts

SharePoint’s permission system is powerful but layered. Access Denied errors are almost never caused by a single, obvious misconfiguration. They emerge from the interaction between file-level permissions, folder inheritance, library versioning settings, site collection features, sharing link tokens, authentication flows, and tenant-level policies.

The most important habit you can develop is systematic diagnosis. Don’t jump to conclusions after checking one thing. Work the checklist, fix what you find, test, and move on. The answer is always there - it’s just a matter of knowing where to look.

Good luck out there. And remember: when in doubt, check the version number first.