Remove unique permissions
Reset items to inherited
Broken inheritance is what makes a library's permissions untrustworthy, and past a certain number of items the only sane fix is to reset them all. This does that, and captures every item's full permission set to a run log first so there is a record of what was there.
What it does
- Which items have their own permissions, and exactly who was granted what on each, before anything is reset.
- What the items will inherit instead: the permissions of each item's parent, which is the folder above it if that folder has its own permissions, otherwise the library.
- A permanent record of the permissions that were removed, in the run log and its report.
How it runs
- Sign in and choose what to scan. Sites or libraries.
- Narrow it down. Filter by name, or to files or folders only, before the scan. These filters are the only way to narrow the run.
- Review the findings. Every item with unique permissions, with the principals and roles granted on it. There is no per-row selection: the reset acts on every item the scan found.
- Confirm, then it runs. The confirmation carries the count, and the permissions cannot be put back automatically. Each item's set is written to the log before it is reset. Cancel offers Finish the current item, Stop now, or Keep running. Nothing is left half-written: an item is either done or not started.
How it works
The scan walks each chosen library and checks, for every file and folder that passes your filters, whether it has its own permissions. For each one that does, it reads every principal granted on it and their permission levels: people, SharePoint groups, security groups, and the hidden groups that sharing links create, which are labelled as sharing links. Limited Access, which SharePoint adds on its own, is left out. An item that could not be read is listed as an error, never dropped.
The reset works item by item, on every item the scan listed. For each one, the full list of principals and their levels is written to a run log on this computer and flushed to disk first. The item is then read again: if it already inherits, nothing is sent and it is recorded as already inherited. Otherwise its inheritance is restored, which removes every permission granted directly on it in one step and makes it take its permissions from its parent folder or library again.
Nothing is merged. The direct grants are not copied to the parent, and the parent's permissions are not changed. Afterwards, whoever the parent gives access can reach the item, and anyone whose access came only from a grant on the item, including through a sharing link on it, loses it.
An item SharePoint refuses to reset is listed with SharePoint's reason, and the run moves on. A Stop, a lost sign-in, or the run log failing to write ends the run before the next item; items already reset stay reset and are in the report. There is no automatic undo: the run log and its report are the record to grant access again from, by hand.
What you need
- Enough rights to manage permissions on the items, which in practice means site collection administrator.
What it will not do
- The direct grants are gone. Restoring them means reading the run log and re-applying them by hand, so keep the report.
- Somebody who could reach an item only through a direct grant loses access immediately.
- Resetting to inherited can also WIDEN access, if the parent folder or library is more permissive than the item was. That is the case worth thinking hardest about.
- Report unique permissions, on the Reports menu, is the read-only look at the same data.