SharePoint 'You don't have permission' — diagnose without admin access

This is one of those problems Microsoft pretends doesn't exist. You click a perfectly normal-looking link to a document, SharePoint thinks for a second, then serves you a polite page that says "You don't have permission to access this file." There's a Request Access button and a deafening silence about why you were denied. You're pretty sure you should have access. You open the link in incognito. Same result.

Welcome to the least-helpful error in all of Microsoft 365.

The vagueness is on purpose, by the way. SharePoint won't tell you what you're missing because that information itself can leak structural details about the site. Which is reasonable in theory. Maddening in practice. So you have to be the detective. Here's how to do it without admin rights, which is what most of you have.

The three layers of SharePoint permissions

Before chasing a fix, get the model in your head. SharePoint permissions are layered, and you can be denied at any one of them.

Level	What it controls	Common cause of denial
Site	Whether you can enter the site at all	You're not a member of any group on the site
Library	Whether you can see the library inside the site	Library has unique permissions and you're excluded
Folder/Item	Whether you can see this specific document	Inheritance was broken and you're not on the item ACL

By default, items inherit from their library, which inherits from the site. Anywhere in that chain, an admin (or anyone using "Share" with specific people) can "break inheritance" and create a unique permission set. That's where about 80% of these errors come from. I've been doing this for nine years and the proportion never changes.

Step 1: Verify what level you're being denied at

Try to walk the URL piece by piece. If your problem URL is something like:

https://contoso.sharepoint.com/sites/MarketingHub/Shared%20Documents/Campaigns/Q3/launch-plan.pptx

Try in this order:

1. Site root: https://contoso.sharepoint.com/sites/MarketingHub. Does the site load?
2. Library: https://contoso.sharepoint.com/sites/MarketingHub/Shared%20Documents. Does the document library load?
3. Folder: https://contoso.sharepoint.com/sites/MarketingHub/Shared%20Documents/Campaigns/Q3. Does the folder list?

The first one that fails is the level at which permission was denied. Which dictates what you need to ask for.

Site root denies you, you need site-level access (Member or Visitor group). Library loads but the file doesn't, the file or its parent folder has unique permissions. Everything loads but the file still says no, the item ACL specifically excludes you. Three different conversations to have with your site owner.

Step 2: The "Check Permissions" tool — and why it usually doesn't help

There's a tool built into SharePoint called Check Permissions that will tell you, for any user, exactly which groups they belong to and what permission level that gives them on a given object. Perfect diagnostic tool. One catch. You have to be a site owner to use it. Which, if you're reading this, you probably aren't.

If you're not an owner but a colleague is, ask them to:

1. Go to the site Settings (gear icon, top right).
2. Site permissions, then Advanced permissions settings.
3. Permissions tab, then Check Permissions button.
4. Type your username, click Check Now.

Result shows your effective permission level on the site, and notes which group it came from. They can walk to the library or item and repeat the same dance there. Check Permissions exists at every scope.

If they get back "User has no permissions on this object" — that's your answer. If they get back "Edit (via group X)" but you still can't open the file, then your auth token is stale. Skip to the bottom section.

Step 3: Broken inheritance — the most common culprit

When someone shares a single file with one person via "Share" and picks "Specific people," SharePoint silently breaks permission inheritance on that file. Same thing happens when an admin clicks "Stop Inheriting Permissions" on a folder.

Once inheritance is broken, the item has its own permission list. Adding new people to the parent library does NOT automatically grant them access to that item. The item is no longer listening to the parent. It's gone independent.

How to spot it

If you're asking a site owner, in the library view they click the file's three-dot menu, then Manage access. The panel shows "Direct access" and any groups. If the only entries are individual names (not groups), inheritance is broken.

For an entire library: Site Settings, Site contents, click the library, gear, Library settings, Permissions for this library. At the top it says either "This library inherits permissions from its parent" or "This library has unique permissions." Plain English. Useful.

What to ask for

If inheritance is broken on purpose (sensitive folder, exec-only content), ask to be added directly. If it's broken accidentally (usually because someone clicked Share on a folder once a year ago and forgot), ask the owner to either re-inherit (which loses all the individual exceptions) or add your group to the broken folder's ACL.

Step 4: Guest accounts and external sharing settings

If you're accessing a SharePoint site that doesn't belong to your own organisation — partner shared a doc from partner.sharepoint.com, say — you're a guest user in their tenant. Three things can go wrong:

1. Their tenant has external sharing disabled entirely. No fix from your side. They have to enable it.
2. Their tenant requires guests to be on an allowlist domain. If your @yourcompany.com isn't on that list, your account can't be added even if someone tries.
3. You accepted the invitation from a different email than the one you're signing in with. Common when work and personal Microsoft accounts collide. Painfully common.

To check which account you're using when accessing the partner site: open https://myaccount.microsoft.com in the same browser session. Top-right shows your active identity. If it's you@personal.com but the invite went to you@work.com, sign out everywhere and re-accept with the right account. Annoying. Mandatory.

Step 5: Sensitivity labels can override everything

Microsoft 365 sensitivity labels (the "Confidential," "Highly Confidential" etc. labels at the top of documents) can encrypt files such that even users with explicit SharePoint permission can't open them. The label's encryption rule has its own ACL, separate from SharePoint's.

Symptoms:

• You can see the file in the library.
• You can download it to your machine.
• Opening it in Word/Excel triggers a "you do not have rights" error from Office, not from SharePoint.

This isn't a SharePoint permission issue. It's an Azure Information Protection / Microsoft Purview issue. Site owners can't fix it. The document author or the label policy owner has to add you to the label's protected user list.

If you suspect this, look at the title bar of the document in Word. A coloured banner saying "Confidential — Internal Only" or similar is your tell.

Step 6: Conditional access policies blocking the session

Your organisation may have an Entra ID conditional access policy that blocks SharePoint access from:

• Unmanaged devices
• Untrusted networks (you're working from a coffee shop)
• Browsers that aren't Edge or Chrome
• Sessions that haven't done MFA in the last X hours

Error often looks identical to a permission denial. Telltale signs:

• Works fine on your office laptop. Doesn't work on your home one.
• Works on Edge. Doesn't work on Firefox.
• Works on the office Wi-Fi. Doesn't work on cellular.
• Error mentions "your sign-in is restricted" or shows a 53003 error code somewhere in the URL.

Fix: switch to a managed device or trusted network. Neither available, check with IT. There's sometimes a per-user exception they can grant. Sometimes not.

Step 7: Private channel files in Teams

Files in a Teams private channel live in a separate SharePoint site. Not the parent team's site. The site name is auto-generated as something like ContosoMarketing-PrivateChannelName. Members of the parent team but NOT the private channel cannot access these files, even though the channel sits inside the team they're on.

Confusing, especially if a colleague says "it's in the marketing channel" and you can see the channel listed in Teams but can't open the file.

If a colleague in your team shares a link to a private channel file and you get permission denied:

1. Confirm with them which channel the file lives in.
2. If it's a private channel, ask them to add you to the channel itself (channel settings, Manage members).
3. SharePoint permission propagates within minutes of channel membership changing.

The Request Access button — does it actually work?

When SharePoint denies you, there's usually a "Request Access" button. It sends an email to whoever the site owner has configured to receive access requests.

Realities, in no particular order:

• The email goes to the address in Site Settings, Access requests and invitations. If no owner has set this, requests vanish into a void. Forever.
• The owner has to manually approve, set a permission level, and assign a group. Many ignore them. I've seen mailboxes with three years of unread access requests in them.
• If the file has unique permissions, granting access at the site level does NOT give you access to the file. The owner has to grant on the file specifically. They often don't know to.

Use the button as a fallback. Don't rely on it. Faster path is direct messaging the file owner with the URL and the level you need (Read, Contribute, Edit).

Edit vs Contribute vs Read — which to ask for

When asking for access, name the level you need. Defaults:

Level	Can read	Can upload	Can delete	Can change permissions
Read	Yes	No	No	No
Contribute	Yes	Yes	Own files only	No
Edit	Yes	Yes	Yes	No
Design	Yes	Yes	Yes	Limited (lists only)
Full Control	Yes	Yes	Yes	Yes

For most "I just need to view this report" requests, ask for Read. For "I'm collaborating on this document," ask for Edit. Ask for Full Control only if you're taking ownership of the site.

Never ask for Full Control casually. Site owners reflexively decline because Full Control includes the ability to delete the site itself, and they're not handing that to anyone they don't fully trust.

Stale token: the easy one to rule out

Sometimes the permission is actually fine and your auth token is just stale. Quick test:

1. Sign out of office.com in your browser.
2. Close all browser windows.
3. Sign back in.
4. Try the link again.

If that fixes it, you were chasing a phantom. SharePoint tokens can hold cached "no permission" responses for several minutes after permission has been granted on the server side. I've seen this take up to twenty minutes to clear on its own. Faster to sign out and back in.

Putting it together

When SharePoint says "you don't have permission," don't just hit Request Access. Diagnose first:

1. Test which level fails (site, library, folder, item) by walking up the URL.
2. Sign out and back in to rule out a stale token.
3. Ask a site owner to run Check Permissions on you.
4. If inheritance is broken on the item, ask to be added directly.
5. Confirm you're signing in with the right account, especially for cross-tenant guest scenarios.
6. Look for sensitivity labels (banner in the document) and conditional access errors (error codes in the URL).
7. For private channel files, check channel membership in Teams.
8. When you ask for access, specify the level. Read, Contribute, or Edit.

The error message will not help you. The walk above will. And it gets you a precise ask to send the site owner instead of "I am denied please help," which is the message I've gotten about four hundred times and which I cannot do anything with.