How to fix SharePoint permissions in Microsoft 365 (inheritance, sharing links, and access requests)

The complaint arrives in one of two shapes. Either somebody cannot open a file that everyone insists they should be able to open, or somebody has just opened a file they were never meant to see. Both come from the same place: a SharePoint site where access has been granted four different ways over three years, and nobody holds a complete picture of who can reach what.

SharePoint permissions are not difficult, but they are layered, and the layers are not all visible from one screen. This guide works through them in the order that actually resolves a problem. Identify the type of site you are in, establish who has access today, rebuild the site on a group-based model, remove the exceptions, control the sharing links, and put access requests somewhere a human will see them.

Before anything else: work out what type of site you are in

SharePoint has several site types and they do not share a permissions model. Applying a communication-site technique to a group-connected team site is the most common reason a permissions change does not stick.

• Team sites are connected to a Microsoft 365 group by default. Group owners become site owners and group members become site members, so permissions are best managed through the group. Adding someone directly in SharePoint gives them the site but none of the other group services, such as the group mailbox, calendar or Planner.
• Channel sites sit behind a private or shared channel in Microsoft Teams. Permissions for these have to be managed in Teams. SharePoint displays them in read-only mode and cannot manage them separately, so channel owners become site owners and channel members become site members whether you like it or not.
• Communication sites are not connected to a Microsoft 365 group and use the standard SharePoint Owners, Members and Visitors groups. This is the site type where the classic permissions techniques apply cleanly.
• Hub sites follow whichever model the underlying site uses, so a group-connected hub is managed through its group and a communication-site hub through its SharePoint groups. Which users may associate other sites to a hub is set by a SharePoint administrator and cannot be changed by site owners.

Step 1: establish who has access today

Change nothing until the current picture is written down. Four places hold parts of it and no single one holds all of it.

The site permissions panel

From the site itself, open Settings and then Site permissions. This shows the site's owners, members and visitors, and on a group-connected team site it shows the group's membership. It is the fast read, and it is also the incomplete one, because it shows nothing that has been granted below the site level.

Advanced permissions settings

From that same panel, open the advanced permissions settings. This is the classic permissions page. It lists every group and every individual holding permission at the site level, and it warns when a list, library or item further down has unique permissions. The page also carries a check-permissions action that resolves exactly what a named person can do on the site, including access they inherit through a security group. When someone insists they have no access and the group membership says otherwise, this is the screen that ends the argument.

Site collection administrators

Site collection administrators hold full control over a site regardless of every other setting on it, and the link to view them is only displayed to accounts holding at least the SharePoint Administrator role. Site owners cannot see it at all. On an inherited tenant this is where a departed consultant, an old migration service account, or a former IT provider is usually still sitting, invisible to everyone who thinks they are reviewing the site.

Manage access on the item itself

Open the Manage access panel on the specific file or folder in question. It shows both direct access and the sharing links that exist for that item. This is normally where the access nobody can account for turns up, because it was never a permission granted by an administrator, it was a link somebody sent.

Step 2: rebuild the site on a group-based model

Permissions granted to individuals are the reason an access review takes a week instead of ten minutes. Rebuild the model on groups first and remove the exceptions second, in that order, so nobody loses access halfway through the repair.

1. 1Decide the three audiences for the site: who administers it, who creates content in it, and who only needs to read it. Nearly every site resolves cleanly into those three.
2. 2On a group-connected team site, set the first two through the Microsoft 365 group or the Teams team. Group owners become site owners and group members become site members automatically.
3. 3On a communication site, add a security group or a Microsoft 365 group into the site's Owners, Members and Visitors groups rather than adding people one at a time. The Visitors group is where a security group earns its keep, because read-only is usually the largest audience.
4. 4Name at least two site owners. A single owner who leaves the business orphans the site and sends every future access request nowhere.
5. 5Do not nest security groups inside other security groups for SharePoint access. Nested groups can cause performance problems and are not recommended.
6. 6Record the model outside SharePoint: site, purpose, owner, and which group holds which level. A permissions model that only exists inside the product is a model that gets undone by the first person in a hurry.

Step 3: find the unique permissions and clear them out

By default every library, folder and file inherits permissions from the site above it. Breaking that inheritance, so one folder behaves differently to everything around it, is available everywhere in SharePoint and is tempting the first time a manager asks for a folder only three people can see.

The cost lands later. Unique permissions are not visible from the site's main permissions screen, so an access review has to walk every library and folder individually to find them. Multiply a few dozen one-off exceptions across a couple of years and a five-minute check becomes archaeology. This is the single most common finding in the sharing reviews Frontrow runs during a Microsoft 365 health check: sites where the top-level permissions look immaculate and several buried folders do not match them at all.

1. 1Open the library, list or folder, then open its permissions page. It will tell you plainly whether the object has unique permissions or inherits them.
2. 2Before removing anything, export or screenshot who currently holds access through the exception. This is the record you will need if somebody loses access.
3. 3Check whether those people already hold access through a site-level group. Often they do, and the exception is redundant.
4. 4If the exception is genuinely still needed by a different audience, move that content to its own library or its own site instead, then return the folder to inheriting.
5. 5Delete the unique permissions so the object inherits from its parent again.
6. 6Re-run the check-permissions action against two or three named people to confirm the result matches what you intended.

Where content genuinely needs a different audience, the structural fix is a separate library or a separate site, not a folder with its own permissions buried inside a library everyone else can see. A separate site appears in the SharePoint admin center's list of sites, shows up in a sharing report, and can be reviewed on a schedule. A folder five levels down gets found by accident.

Step 4: sharing links are permissions too

A large share of the access nobody can explain was never granted through a group. It was granted by somebody pressing Share. SharePoint offers four link types and they behave very differently.

• Anyone with the link gives access to anyone holding the link, including people outside the organisation. People using an Anyone link do not have to authenticate, and their access cannot be audited. These links also cannot be used with files in a Teams shared channel site.
• People in your organisation with the link works for anyone inside the Microsoft 365 organisation. It does not work for guests, or for external participants in Teams shared channels.
• People with existing access creates a link that grants nothing new and only works for people who already have access. It is the correct link to paste into a Teams chat when everyone in the chat is already on the site.
• Specific people works only for the people named at the moment the item was shared, which makes it the auditable option.

The control that matters more than any amount of user training is the default. Set a restrictive default link type and users keep the ability to choose something else, they simply stop choosing Anyone by reflex.

1. 1In the SharePoint admin center, open Active sites and select the site.
2. 2Select Sharing on the command bar.
3. 3Under Default sharing link type, clear the 'Same as organization-level setting' checkbox and choose the link type you want as the default for this site, then save.
4. 4Repeat under Default link permission so the default is view rather than edit where that suits the site.
5. 5Set the organisation-level position first, in the external sharing settings, so every new site starts from the right default rather than being fixed one at a time.
6. 6For a Teams private or shared channel site, the default link type has to be changed with the Set-SPOSite cmdlet in PowerShell; the admin center will not do it.

If sensitivity labels are already in use, the default sharing link type and link permission can be carried by the label instead, which travels with the content rather than sitting on the site.

Step 5: access requests, so the fix survives contact with users

A tidy permissions model fails the moment somebody legitimately needs access and there is no route to ask for it. What follows is a phone call to a colleague, a file emailed as an attachment, or an Anyone link, and the model is undone.

Access requests are configured from the site's permissions settings, and only site collection administrators, SharePoint administrators, and members of the site's default Owners group can use the Access Requests page for a site. Three things are worth checking rather than assuming.

• The address requests are sent to. On an inherited tenant it is often a person who left two years ago, which means every request since has gone into a void and users have long since stopped bothering.
• Whether anyone is actually processing the queue. Requests accumulate silently; nobody is notified that nobody is looking.
• What happens on group-connected sites, where the request routes to the group owners. If the group has one owner, or an owner who has left, the same dead end applies.

The traps that put a site straight back where it started

• Solving one person's problem by granting access to 'Everyone except external users'. It reads like a narrow fix and resolves to every licensed user in the tenant. It is almost never what was intended.
• Fixing an access problem at item level. It works in ten seconds and creates precisely the exception that the next review has to hunt down.
• Assuming a SharePoint permission change reaches Teams. On a channel site it does not, and the work has to be done in Teams instead.
• Leaving guests in place after a project ends. Guest accounts persist until somebody removes them, and the project folder they were invited into usually persists too.
• One site owner. Every orphaned site in every tenant started with one owner who was still employed at the time.
• Treating a departed staff member's account as harmless because 'they've gone'. Until the account is disabled and removed from its groups, everything it could reach is still reachable.
• Reviewing permissions once, at build time. Sites drift, because the people using them are trying to get work done and sharing is the fastest path in front of them.

A model that holds up in a real business

Take a 70-person civil contractor with offices in Townsville and Mackay, which is a shape Frontrow sees often. The version that works is not complicated. One communication site acts as the intranet, with everyone in Visitors through a security group and a small content team in Members. One group-connected team site per business function, so finance, HR, plant and safety each have their own, with membership managed through the Microsoft 365 group and no folder-level exceptions inside any of them.

Project sites get created per major job, associated to a projects hub for shared navigation, and are archived when the job closes rather than left running indefinitely. Anything shared with a client, a subcontractor or an engineering consultant lives on a separate site that has external sharing enabled, while every other site has it turned off, so a guest invitation cannot reach payroll records even by mistake. Access requests on every site point at a monitored address, not an individual.

None of that requires a licence upgrade or a migration. It requires the decisions to be made once, deliberately, and then held.