A SharePoint document library is a file container on a SharePoint site: columns, version history, and permissions. People often meet it as the Files tab in Teams. OneDrive vs SharePoint decides which product owns the file. This guide is how libraries and access work once the file is on a site.
A SharePoint Administrator can change tenant-wide sharing. A site owner can change that site. Those are different jobs.
Sites, libraries, and folders
A site (for example a Team site or a communication site) has owners, members, and visitors. Those groups are the default permission set.
A library lives on the site. “Documents” is the default library. You can add more libraries when the files have different retention or a different audience (Contracts vs Marketing assets).
A folder is a grouping inside a library. It inherits the library’s permissions unless someone breaks inheritance. Version history and recycle bin are at the file and library level, not “the folder product.”
Private Teams channels use a separate site. That is why a private channel’s Files tab does not follow the parent Team’s member list one-for-one.
Inheritance, and when to break it
By default, a file sees the same people as its library, which sees the same people as the site. Adding a member to the Team or the site group is the scalable way to grant access.
Breaking inheritance on a folder creates unique permissions. Use it rarely: a payroll folder inside an HR site, or a board pack. If every folder has unique permissions, nobody can predict who sees what, and links start to fail when groups change.
Sharing a link is a grant on that object. A “anyone” link ignores your careful groups. Tenant external sharing settings decide whether those links can leave the organisation.
Giving access without unique-permission sprawl
- Put the file on the site that already has the right owners and members
- Use a separate library if the audience is permanently different
- Add people to the site or Team group, not to each folder
- Break inheritance only for a small, named exception
- Review unique permissions and sharing links on a schedule
Versions, checkout, and recycle bin
Version history lets you restore a previous copy after a bad edit or a ransomware-like mass change, within retention limits. Require checkout only if two people truly cannot edit together; it becomes a lock that people forget.
Deleted files go to the site recycle bin, then a second-stage bin, then they are gone. Library quotas are not the same as OneDrive quotas. A full library is a storage problem, not a permission problem.
Columns (status, year, client) and views filter a large library. Deep folder trees that copy the org chart are harder to permission and to search.
A practical example
Finance stores everything in one “Shared” library and breaks inheritance on twenty client folders. A new accountant cannot see last year’s files and nobody knows why. The revision creates a Finance site, a Working library for the team, a Restricted library for payroll with a small owner group, and leaves client work as folders that inherit Working. Client-external sharing uses a named guest on a dedicated library, not “anyone” links.
Key takeaways
- Library permissions inherit from the site unless you break them.
- Prefer a second library or a second site over unique permissions on every folder.
- Site owner is not the same as tenant SharePoint Administrator.
- Versions and recycle bins are per library, not magic for the whole tenant.
FAQ
Should we hide a library instead of permissioning it?
Hiding is not security. People with a link or a search result may still open it. Use real permissions.
Can visitors edit files?
Visitors are usually read-only. Members can edit. Owners can change structure. Adjust the group, do not grant Edit to everyone as a shortcut.
Why does a Teams Files tab look different from SharePoint in the browser?
It is the same library with a simpler shell. Columns, permissions, and recycle bin are still in SharePoint.