SharePoint permission inheritance

By default every list, library, folder and item inherits its permissions from the

site. Inheritance can be broken at any level, which replaces the inherited set

with a unique one that no longer tracks changes made above it.

That is the mechanism behind almost every "access denied on one library while the

rest of the site is fine" ticket.

The tell is a scoped failure: several users lose access to exactly one object,

while the same users still work everywhere else on the same site. That pattern rules

out identity, licensing and client faults immediately — none of those are

object-scoped.

The second tell is who still works. If the people who retain access have a direct

grant and the people who lost it were members of a group, inheritance was broken and

the group was not carried over.

Check inheritance across the site. Find every scope with unique permissions.
Read the unique permissions on the failing object. Compare against the site-level

permissions — what is present at the site and missing on the object?

That is both your cause and your change record.

Restoring inheritance is usually correct. It removes the unique permissions and

re-establishes the site's set — including the group grant that everyone was relying

on.

Before you do, confirm that nobody is depending on the unique permissions for

something legitimate. If a library was deliberately restricted, restoring

inheritance silently widens access to everyone with site access. Read what the

unique set contains before you delete it.

Adding individual grants to the failing users is the tempting alternative. It

works today, and it leaves the underlying break in place plus a set of direct grants

that nobody will remember. The next reorganisation reproduces the same ticket.

Never resolve an access-denied by granting more than was there before. Adding

Everyone except external users, or making the requester a site collection

administrator, makes the symptom go away and leaves a permanent exposure.

Have an affected user confirm from their own machine. The console reporting success

is not the same as a person being able to open a document — sync clients in

particular can take a while to recover, and may need to be signed out and back in.

Grant through groups, not to individuals. Group grants survive reorganisations.
Break inheritance only where there is a genuine confidentiality boundary.
When you must break it, add the same groups back deliberately, not the people who

happened to complain first.