SharePoint Document Library Permissions (Without Breaking Sharing)

Most SharePoint “security” tickets I see are not sophisticated attacks. They are inheritance accidents: someone shared a folder to fix a Friday deadline, Unique permissions multiplied, Limited Access ghosts appeared, and six months later nobody can explain who sees the contracts library.

Permissions are where DMS ambition dies quietly. You can have beautiful content types and still fail an access review because Contribute was granted to named people instead of groups, or because “Anyone with the link” became the unofficial external portal.

This post is the practitioner version: when each permission scope is justified, why unique permissions explode, how to share safely for company documents, and how to diagnose “why can’t I open / edit this?”

Site vs library vs folder vs item

SharePoint lets you break inheritance at almost every level. That flexibility is also the trap.

Site permissions — default Members / Visitors / Owners (or M365 group membership for team sites). Use this for “who belongs in this workplace.” Most company document libraries should inherit from here.

Library permissions — justified when one library on a site is more sensitive than the rest (HR on a broader intranet site, Legal contracts beside a working drafts library). Prefer a dedicated site when the sensitivity difference is large; unique library permissions are fine when the exception is clear and documented.

Folder permissions — sometimes justified for a sealed sub-area (e.g. “Board only” under a leadership library). Overused, they become a second taxonomy. If every folder has different people, you rebuilt NTFS ACLs in the cloud.

Item (file) permissions — last resort. Valid for a single sealed exhibit or a temporary review pack. Dangerous as habit. Item-level unique permissions are how you get support queues that cannot answer “who has access?” without exporting reports.

Rule of thumb I use on designs: groups at site (or library) level; folders for navigation and metadata, not for access design; items almost never. Pair with metadata vs folders so structure and security do not fight each other.

Why unique permissions explode (and Limited Access)

When you share a file or folder with someone who is not already a site member, SharePoint often grants Limited Access at parent containers so the user can reach the shared item without seeing everything else. Those Limited Access entries are not “extra roles you meant to invent.” They are scaffolding. They accumulate.

Symptoms:

• Permission reports full of Limited Access you did not plan
• “I can open this one file but the library looks empty”
• Inheritance broken on hundreds of items after a year of ad-hoc sharing
• External sharing links that outlive the project

Cleanup means restore inheritance where safe, move sealed content to a tighter library, replace person shares with groups, and delete stale links. Prevention is cheaper. If the estate still behaves like a network drive of personal shares, fix landing patterns in migration: network drive to SharePoint.

Group-based access over person-based

Company documents should grant access to Entra ID / Microsoft 365 groups (or SharePoint groups backed by those), not to long lists of named users.

Why:

• Joiner/mover/leaver becomes group membership, not editing 40 libraries
• Access reviews have a clear object (“Contract Approvers”)
• You can align roles authors, approvers, readers to business language

Person-based sharing is fine for a one-off partner review with an expiry. It is not a DMS access model. The same discipline shows up in regulated control work: document control for ISO, SOX, GDPR.

External sharing links vs guest access

For controlled company docs I separate three patterns:

1. Internal only sharing links restricted to people in the organisation; prefer group membership over links when the person needs ongoing access.
2. Guest (Entra B2B) named external user in the directory, auditable, can be removed, can sit in a group. Prefer this for ongoing vendor or auditor access to a library or site.
3. Anyone / anonymous links convenient, weak for controlled documents. If policy allows them at all, short expiry, specific file, never for the system-of-record library as a whole.

“Sharing externally to non-members” is not one button. Decide whether the outsider is a temporary recipient of one PDF or a recurring collaborator. Recurring → guest + group. One PDF with expiry → restricted link if policy allows. Regulated SOP → usually neither without a documented exception.

Purview retention and labels do not replace access design; they complement it: Purview retention for SharePoint documents.

How to share a file safely (company documents)

Practical sequence I teach power users:

1. Confirm the file lives in the correct SharePoint library (not OneDrive, not chat) see SharePoint vs OneDrive vs Teams.
2. Prefer adding the person/group to the site or library role if they need ongoing access.
3. If a link is required: people in your organisation or specific people, not Anyone, for anything non-public.
4. Set expiry and view-only when edit is unnecessary.
5. Avoid “stop inheriting” on the item unless you have a written reason and an owner who will clean it up.
6. For Teams: share the library/channel file link, not a fresh OneDrive copy uploaded into chat.

Safe sharing is boring. That is the point.

Diagnosis checklist: “Why can’t I access / edit this file?”

Work top-down. I keep this list on engagements:

User side

• Are you signed into the correct tenant / work account?
• Do you have a sharing link vs site membership? Links can grant open without “I belong here” navigation.
• Is the file checked out to someone else, or required checkout enabled?
• Is there an IRM / sensitivity label blocking download or edit?
• Are you looking at a Teams chat copy vs the channel library copy?

Permissions

• Site Members vs Visitors vs unique library permissions?
• Broken inheritance on folder or item? Unique permissions report.
• Limited Access only can open shared item but not browse parent?
• Guest account invited to a different address than the one in use?
• Conditional Access / device compliance blocking Office clients?

Library settings

• Draft item security / major-minor versions readers cannot see minor drafts
• Content Approval pending items hidden from general readers
• Required metadata / content types blocking upload or save that users describe as “can’t edit”

Admin / audit

• Sharing link expired or revoked
• User removed from the M365 group behind the team
• Retention/hold confused with access (different issue, same ticket)

Most tickets resolve at “wrong copy,” “Visitors not Members,” or unique permissions from an old share. Search and Copilot will not show files you cannot open — trimming so findability complaints often start as access design: why SharePoint search can’t find your file, why Copilot returns the wrong document.

DMS angle: roles and audit-oriented patterns

A document management system needs access that matches roles Document Controller, Approver, Reader and an audit story you can explain. SharePoint can model that with groups and least privilege. It will not invent the role model for you.

When teams want those controlled behaviours packaged role-oriented permissions patterns, approvals, templates, audit-oriented trails on top of libraries that already sit in the customer tenant, that is the soft path to DocVault: data stays in tenant, unlimited users, one-time flat fee (see product page). Architecture context: document management system guide. Whether SharePoint alone is “enough” remains a design question: can SharePoint be a DMS?, build vs buy, cost framing.

It depends on whether you treat permissions as a Friday workaround or as part of classification, lifecycle, control, and access. Unique permissions-on-everything rarely survives the first serious access review.