"Specific People" sharing-link group with a member but no role assignment and a non-existent target document

Please note that Q&A forum is a public platform, and moderators will modify the question to hide personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi @Ali Jone

Based on the API outputs and behavior you shared, I understand that you have discovered an orphaned SharingLinks.* hidden site group (ID 67) containing an external guest member on a SharePoint Online site. However, the specific document GUID embedded in the group name returns a 404 Not Found, and there are absolutely no active role assignments matching this group at the Web, List, or Item levels. Furthermore, this guest appears in raw API queries and the hidden people.aspx?MembershipGroupId=0 view but completely disappears from official SharePoint Sharing and Membership compliance reports.

Here is the technical breakdown of why this phenomenon occurs, answers to your specific questions, and how to programmatically detect and clean up these resources.

1.The presence of a SharingLinks.* group does not guarantee an active sharing permission. These groups are backend artifacts created by the SharePoint architecture the moment a "Specific People" sharing link is generated.

A group can exist without a corresponding role assignment under two main circumstances:

• The link was deleted or expired: If an owner removes the specific sharing link or it hits an expiration policy, SharePoint often tears down the RoleAssignment link but fails to garbage-collect the underlying Site Group entity.
• Permission Inheritance was reset: If a document library or folder has its unique permissions deleted and reverted back to Inheriting Permissions from the parent site, the explicit item-level role assignments are instantly wiped out, but the structural hidden sharing groups remain left behind.

2.When a document is permanently deleted (and purged from the Recycle Bins), the explicit database map connecting the file to its permissions is broken.

The expected behavior should be a cascading deletion of related entities. However, in SharePoint Online's distributed cloud architecture, SharingLinks.* groups frequently become orphaned security principals. They persist indefinitely in the site's User Information List (SPWeb.SiteUsers) and Group collection because there is no automatic background garbage-collection process to scrub hidden groups tied to dead GUIDs.

3.After researching, there is no official, built-in API endpoint natively designed to reverse-map a SharingLinks.* token to an object or flatly flag it as "Orphaned."

The method you used is actually the industry standard and only reliable logic pattern available:

1. Parse the document GUID embedded in the SharingLinks.<GUID>.<type>.<shareId> string name.
2. Execute a conditional GetFileById and GetFolderById query.
3. Scan the site-wide and unique item-level RoleAssignments.
4. If the file returns a 404 AND no RoleAssignment matches the group ID across the scopes, the group can safely be flagged as an orphan.

4.The difference comes down to what each interface is querying:

• SiteGroups and people.aspx: These show a raw directory dump of all principals that have ever been structurally provisioned inside this specific site collection storage bucket. It displays historical footprint data, not live access mapping.
• Generated Membership & Sharing Reports: These are compliance-driven engines. They do not care if a user merely exists in a group; they only report on active access paths where a valid RoleAssignment links a principal to an existing asset. Because your group lacks a RoleAssignment, the reporting engine recognizes that the guest cannot actually open any data and correctly omits them from the access report.
• The Authoritative Surface: For auditing "Who currently has true access to data," the RoleAssignments endpoints are the absolute source of truth.

To resolve this and clean up your environment, you can use the following approach.

Since the group is orphaned, you can explicitly remove the guest member from the hidden group using the script block below. This will scrub their profile footprint from SiteGroups:

# Connect to the site
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/your-site" -Interactive
 
# Find the orphaned SharingLinks group (replace with actual prefix from the group Title/LoginName)
$group = Get-PnPGroup | Where-Object { $_.Title -like "SharingLinks.26dff45d*" -or $_.LoginName -like "*SharingLinks.26dff45d*" }
 
if ($group) {
    Write-Host "Found group: $($group.Title) (ID: $($group.Id))" -ForegroundColor Yellow
    # Remove the specific guest member
    Remove-PnPGroupMember -Group $group -LoginName "******@domain.com" -Force
    Write-Host "Removed guest member from the group." -ForegroundColor Green
    # Optional: If the group is now empty, try to delete it (system groups may resist deletion)
    # Remove-PnPGroup -Identity $group.Id -Force
}

If you want to build an internal reporting automation framework to detect these across your broader client tenants, I suggest writing a script that loops through /_api/Web/SiteGroups, extracts any group containing the prefix SharingLinks., splits the string to extract the secondary block (the File GUID), and executes a try/catch error assessment block against GetFileById(). Any group triggering an HTTP 404 can be instantly queued for automated deletion.

Please try removing the member/group using the PnP script above, and let me know if it successfully clears the user footprint from your raw API views.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".  

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.