In this post: Overview · How to Check on Users Permission Site Collection Wide · Determining access to a specific list or library · Why removing someone doesn’t always remove their access · Doing the same check from PowerShell · Related reading
Overview
One of the most common issues SharePoint users run into is “Why don’t I have access to this site? Can you give me access?” or “Wait, do you see anything? Because I don’t see any files in this folder.” SharePoint’s permission structure gets complicated fast, especially once sites, files, or lists have unique permissions. Sometimes you remove a user’s permission at the site level and are pretty sure they no longer have access, but it turns out they can still see all the files. SharePoint permissions get messy when not administered carefully, so it’s worth double-checking permissions on sites and files even after removing someone at the site level.
How to Check on Users Permission Site Collection Wide
On the ribbon, click the Check Permission button.
From there you can see the permission a user has and which group they were added through. In this case, the user can Read and Edit files, pages, and lists Site Collection Wide, since we’re looking at the site collection level of permission.
How to Determine if That User Has Access to Your List and Document Libraries
First, go into the specific list or document library, click the gear icon in the top-right corner, and click ‘Library settings‘ for a document library, or ‘List settings‘ for a SharePoint list.
Notice the buttons in the ribbon: ‘Manage Parent‘ and ‘Stop Inheriting Permission‘. These identify that the document library or list is currently inheriting the permission structure of the site collection.
Checking a specific user’s permission here follows the same process used for the site collection above.
Why removing someone doesn’t always remove their access
The Overview above describes exactly this mystery — remove someone at the site level, and they can still see everything — without actually naming the usual causes. The Check Permission tool tells you what access someone currently has; it doesn’t explain why a removal didn’t take effect. Three real culprits, roughly in order of how often they’re the actual answer:
- A sharing link, not group membership. Someone shared a specific file or folder with that person directly via a link at some point — that access lives independently of the site’s SharePoint groups entirely, so removing them from “Site Members” does nothing to a link they already have.
- Item- or folder-level unique permissions. If the specific file or folder they’re accessing has broken inheritance (the “Stop Inheriting Permission” state covered above), it keeps its own permission list — removing someone from the site or library level doesn’t touch permissions granted directly at that lower level.
- Indirect membership through a nested Entra ID (Azure AD) security group. If the SharePoint group’s access was granted to a security group rather than individual users, removing someone from the SharePoint group does nothing if they’re still a member of that underlying security group — the actual fix is removing them from the security group, not the SharePoint group.
The PowerShell check further down answers “what do they have now,” same as the UI tool — neither one tells you which of these three is the actual cause on its own. Checking item-level permissions specifically (the third code example below) and reviewing shared links on the file in question are usually the fastest way to actually find the source, rather than re-checking site and library permissions repeatedly and getting the same confusing “yes, they still have access” result.
Doing the same check from PowerShell
The UI-based Check Permission tool above is fine for a one-off lookup, but it doesn’t scale to “audit every user’s access across this site” or “check this same user against fifty lists.” PnP PowerShell’s Get-PnPUserEffectivePermissions answers the exact same question — what does this user actually have access to — at each of the same three scopes the UI walkthrough above covers:
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/YourSite" -Interactive
# Site-collection-wide, same as the first Check Permission screenshot above
Get-PnPUserEffectivePermissions -User "user@yourtenant.com" | Format-List
# Scoped to one list or library, same as the second half of this post
Get-PnPUserEffectivePermissions -User "user@yourtenant.com" -List "Documents" | Format-List
# Scoped to a single item -- narrower than either UI check above
Get-PnPUserEffectivePermissions -User "user@yourtenant.com" -List "Documents" -Identity 5 | Format-ListThe item-level scope is worth calling out specifically, since it’s not something the UI walkthrough above has an equivalent for at all — useful for the exact “why can this one person still open this one file” question that unique, item-level permissions can create. Looping this across every user in a group, or every list in a site, turns a manual click-through into an actual permissions audit — worth reaching for once “check this one user on this one list” turns into “check everyone, everywhere.”
Get-PnPUserEffectivePermissions answers the same “what can this user actually access” question as the Check Permission UI, at site, list, and item scope — the item-level scope has no UI equivalent at all.
Related reading
- All about SharePoint Permission Roles — what the permission levels shown by Check Permission actually grant.
- Breaking SharePoint Permission Inheritance — more on the unique-permissions state the Stop Inheriting Permission button above creates.
Now that’s another tip from TipsByBits! This is just a small slice of a wide topic and things to consider when dealing with SharePoint permission issues, but it’s a genuinely helpful starting point for figuring it out.
Hope it helps somehow. Let us know your thoughts, or if you have anything to add, in the comments.
Happy SharePointing! #SharingIsCaring
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning