You need to break permission inheritance on a SharePoint site or library to give specific users unique access. Later, you want to restore inheritance to simplify management. But when you restore inheritance, SharePoint removes all unique permissions, including the site owner accounts you set up. This leaves the site without owners, causing access problems and support tickets. This article explains why owners get removed and shows a safe workflow to restore inheritance while keeping the right owners in place.
Key Takeaways: Restoring Inheritance Without Losing Site Owners
- Site Settings > Site Permissions > Inherit Permissions: Restores permission inheritance but removes all unique permissions, including owners added after breaking inheritance.
- Site Settings > Site Permissions > Check Permissions: Verifies which users and groups have direct access before you restore inheritance.
- Site Settings > Site Permissions > Permission Levels: Lists the exact permission levels assigned to owners, members, and visitors before you make changes.
Why Restoring Inheritance Removes Site Owners
SharePoint permission inheritance works like a parent-child relationship. When you break inheritance on a site, library, or list, SharePoint creates a copy of the parent permissions for that item. You can then add or remove users on the child item without affecting the parent. This is useful for granting specific access to a project site or a sensitive document library.
When you restore inheritance, SharePoint deletes the child permission copy and reverts to the parent permissions. Any unique permission entries you added at the child level are lost. This includes owner accounts you added only at the child site level. If the parent site does not have those same owners, the child site ends up with no owners after restoration.
How SharePoint Handles Owner Groups
By default, each SharePoint site has three security groups: Owners, Members, and Visitors. When you create a new site from a template, these groups inherit from the parent site. If you break inheritance and add a new user to the Owners group, that user exists only on the child site. Restoring inheritance removes that user from the child site’s Owners group because the parent site’s Owners group does not include them.
What Happens to Unique Permissions on Lists and Libraries
The same behavior applies to lists and libraries. If you break inheritance on a document library and add a user with Edit permissions, restoring inheritance removes that user. However, the list or library does not have its own owner group. The risk there is losing access for users who need to edit documents. The bigger risk is at the site level, where losing owners means no one can manage site settings.
Safe Workflow to Restore Inheritance and Keep Owners
Follow this workflow to restore permission inheritance on a site while ensuring the correct owners remain. This method works for SharePoint Online and SharePoint Server 2016 or later.
- Check current unique permissions on the site
Go to Site Settings > Site Permissions. Under the ribbon, click Check Permissions. Enter the name of a user you know should have owner access. If the result shows Direct access, that user was added after breaking inheritance. Note all users and groups that have direct access, especially in the Owners group. - Add the target owners to the parent site’s Owners group
Navigate to the parent site. Go to Site Settings > Site Permissions. Click the Owners group name. Add the users you want to keep as owners after inheritance is restored. This step ensures the parent site’s Owners group includes those users. Wait a few minutes for the change to propagate. - Verify the parent site permissions
On the parent site, use Check Permissions to confirm the users now appear with Inherited access. If they still show Direct access, the parent site itself may have unique permissions. In that case, repeat steps 2 and 3 up the site hierarchy until you reach a site that inherits from the tenant root or a top-level site collection. - Restore inheritance on the child site
Return to the child site. Go to Site Settings > Site Permissions. Click Delete Unique Permissions (labeled Inherit Permissions in some versions). Confirm the warning that all unique permissions will be removed. Because you already added the target owners to the parent site’s Owners group, they will appear in the child site’s Owners group after inheritance is restored. - Verify the restored permissions
After inheritance is restored, go to Site Settings > Site Permissions. The message at the top should read This site inherits permissions from its parent. Click Check Permissions and enter each owner’s name. They should show Inherited from parent. Also confirm that the Owners group on the child site now matches the parent site’s Owners group.
Restoring Inheritance on Lists and Libraries
For lists and libraries, the same principle applies but the risk is lower because there is no owner group. To restore inheritance on a list or library without losing access for key users:
- Record the unique permission entries
Go to the list or library. Click the gear icon > Library Settings (or List Settings) > Permissions for this document library. Note every user and group that has direct access and their permission level. - Add those users to the parent list or library
Navigate to the parent site where the list or library inherits from. Add the same users with the same permission levels. For example, if a user had Contribute on the child library, add them to the parent library with Contribute. - Restore inheritance on the child list or library
Go back to the child list or library. Click Delete Unique Permissions (Inherit Permissions). Confirm the action. - Verify access
Check permissions for each user to confirm they now inherit from the parent.
If Permissions Still Break After Restoring Inheritance
Users Lost Owner Access After Restoring Inheritance
If a user loses owner access after restoring inheritance, it means you did not add them to the parent site’s Owners group before restoring. To fix this, go to the parent site, add the user to the parent Owners group, and check that the child site shows inherited permissions. The user will gain access within a few minutes. If the child site still shows broken inheritance, repeat the restoration process.
Restored Inheritance But the Site Shows Unique Permissions Again
This indicates that someone or a process broke inheritance again after you restored it. Check the site’s audit logs in the SharePoint admin center under Audit Log Search. Look for events with activity Breaking inheritance. If you find a user or service account breaking inheritance, you need to address that before restoring again.
Cannot Click Inherit Permissions Because the Button Is Grayed Out
The Inherit Permissions button is grayed out when the site already inherits permissions. Check the message at the top of the permissions page. If it says This site inherits permissions from its parent, no action is needed. If it says This site has unique permissions, but the button is still grayed out, you may not have permission to change permissions. Contact a site collection administrator or a tenant admin.
Before and After: Permission Inheritance Comparison
| Item | Before Restoring Inheritance | After Restoring Inheritance |
|---|---|---|
| Site permissions | Unique permissions on the child site | Inherited from the parent site |
| Owner accounts on child site | May include users not in parent Owners group | Match the parent site’s Owners group exactly |
| Permission management | Must manage permissions on each child site separately | Manage permissions from the parent site |
| Risk of losing access | High if owners are only on the child site | Low if owners were added to the parent site first |
This workflow gives you control over which owners remain after restoring inheritance. The key step is adding the target owners to the parent site before restoring. After you complete the restoration, use the Check Permissions tool to confirm that all users have the correct inherited access. For sites with deep permission hierarchies, consider using SharePoint admin center reports to audit unique permissions across all child sites.