Sorry You Do Not Have Access to This Page: Admin Checklist

When users click a SharePoint site or page and see “Sorry, you do not have access to this page,” they cannot proceed with their work. This error can occur for many reasons, from simple permission misconfigurations to deeper issues with site membership or sharing policies. In many cases, the root cause is that the user is not a member of the correct SharePoint group or Microsoft 365 group. This article provides a systematic checklist for administrators to diagnose and resolve this access error quickly.

Why SharePoint Shows Access Denied for Authorized Users

SharePoint uses a layered permission model. The most common cause of the “Sorry, you do not have access” error is that the user is not a direct member of the site’s default SharePoint group (Members, Owners, Visitors) or the associated Microsoft 365 group. Even if the user has access to the parent site, a subsite or specific page may have unique permissions that exclude them. Another frequent cause is that the site has external sharing disabled, and the user is from outside the organization. The error can also appear if the user’s session is stale or if the site is in read-only mode due to a policy or site lock.

For administrators, the error message itself does not specify the reason. The checklist below covers the most likely scenarios and provides the exact steps to fix each one. Each item in the checklist addresses a specific configuration point in SharePoint, Microsoft 365, or Azure Active Directory.

Admin Checklist: Step-by-Step Diagnosis and Fix

1. Confirm the user is a site member
   Open the SharePoint admin center. Go to Active sites and select the site. Click the Permissions tab. Under Site permissions, check if the user is listed as a Member, Owner, or Visitor. If the user is not listed, click Add people and add them to the appropriate group.
2. Verify Microsoft 365 group membership
   If the site is connected to a Microsoft 365 group, go to the Microsoft 365 admin center. Under Groups, find the group that matches the site name. Click the group and go to the Members tab. Confirm the user is listed. If not, click Add members and select the user.
3. Check external sharing settings
   In the SharePoint admin center, go to Policies > Sharing. Under External sharing, ensure the level matches your needs. For the specific site, go to Active sites, select the site, click the Policies tab, and verify the external sharing setting. If the user is external, set the site sharing to Allow external users who accept sharing invitations.
4. Review unique permissions on the page or subsite
   Navigate to the site. Go to Site settings > Site permissions. If the page or subsite has unique permissions, click the link and check the permission groups. Add the user to the appropriate group for that specific item.
5. Clear the user’s browser cache and cookies
   Ask the user to close all browser windows, then clear cache and cookies for the SharePoint domain. Alternatively, instruct them to open an InPrivate or Incognito window and try again.
6. Check if the site is locked or in read-only mode
   In the SharePoint admin center, go to Active sites. Look at the Status column. If the site shows Locked, click the site and select Unlock. If the site is in read-only mode, check the site policies.
7. Verify the user’s Azure Active Directory account is active
   In the Microsoft 365 admin center, go to Users > Active users. Find the user and check the Sign-in status. If it shows Blocked, click the user and select Unblock sign-in.
8. Check for site collection-level permissions using PowerShell
   Open SharePoint Online Management Shell. Run Get-SPOSite -Identity https://yourtenant.sharepoint.com/sites/sitename and check the LockState property. If it is not Unlock, use Set-SPOSite -Identity https://yourtenant.sharepoint.com/sites/sitename -LockState Unlock.

After each step, ask the user to refresh the page. If the error persists, proceed to the next item on the checklist.

If the Access Error Still Appears After the Checklist

SharePoint site shows access denied for site owners

If a site owner sees the error, the site may have been locked by a policy. Check the SharePoint admin center for any data location policies or sensitivity labels applied to the site. Also verify that the site is not in a geo-restricted location where the user’s region does not match.

External users see access denied after accepting invitation

This often occurs when the external sharing setting for the site is set to Only existing external users. Change the setting to New and existing external users in the site’s Policies tab. Also ask the external user to click the invitation link again, not a bookmark.

Access denied on a specific document library

If the user can access the site but not a library, the library likely has unique permissions. Go to the library, click Settings > Library settings > Permissions for this document library. Stop inheriting permissions and add the user directly.

Access denied on a modern page that uses a restricted audience

Modern pages can have audience targeting enabled. Check the page settings in edit mode. Under Audience, ensure the user is included in the targeted group. If audience targeting is not set, remove any audience filter to allow all site members.

Common Permission Scenarios: Site Groups vs Microsoft 365 Groups

Item	SharePoint Site Groups	Microsoft 365 Group
Where membership is managed	Site settings > Site permissions	Microsoft 365 admin center > Groups
What it controls	Access to the SharePoint site only	Access to the site, mailbox, calendar, and Planner
How to add a user	Click Add people in site permissions	Click Add members in group properties
Effect on site access	User gets immediate site access	User gets access after group sync (up to 15 minutes)
Best for	Classic sites or sites with unique permissions	Modern team sites and unified collaboration

Use the checklist in this article to resolve the “Sorry, you do not have access to this page” error in most cases. Start with the site permissions check and the Microsoft 365 group membership verification. If the issue continues, inspect external sharing policies and unique permissions. As a final step, run the Get-SPOSite PowerShell command to check the site lock state. This systematic approach saves time and avoids random permission changes.