When you share OneDrive files or folders with external clients using a sharing link, recipients sometimes see an Access Denied error instead of the file. This problem stops project collaboration and creates confusion about whether the link was sent correctly. The cause is usually a combination of tenant-wide sharing policies, site-level permissions, and link configuration settings that block external access. This article provides a step-by-step admin checklist to diagnose and fix each layer so external sharing links work as expected for client projects.
Key Takeaways: Diagnose and Fix Access Denied on External OneDrive Links
- Microsoft 365 admin center > Settings > Org settings > SharePoint > Sharing: Controls the tenant-level external sharing policy that applies to OneDrive and SharePoint
- OneDrive admin center > Sharing > External sharing: Sets the default link type and expiration for new OneDrive sharing links
- OneDrive admin center > Sync > Advanced settings: Manages sync restrictions and file type blocking that can interfere with external access
- SharePoint Online Management Shell > Set-SPOTenant -ExternalServicesEnabled $true: Ensures external sharing capabilities are enabled at the tenant level
Why External Sharing Links Show Access Denied
OneDrive external sharing relies on three permission layers that all must allow access. The first layer is the tenant-level sharing policy in the Microsoft 365 admin center. If this policy is set to Only people in your organization, no external sharing link will work, regardless of other settings. The second layer is the site-level or OneDrive-level sharing setting in the OneDrive admin center. Even if the tenant allows external sharing, each user’s OneDrive can be restricted to internal sharing only. The third layer is the specific link configuration chosen by the user who creates the link. A link set to People in your organization will fail for external recipients even if the tenant and site allow external sharing.
A fourth less common cause is that the external recipient’s account is blocked by conditional access policies, IP restrictions, or domain allow/block lists configured in Azure Active Directory. Finally, the file itself may be blocked by file type restrictions set in the SharePoint admin center. Each of these layers must be checked in order to resolve Access Denied errors for client project links.
Admin Checklist to Fix External Sharing Access Denied
Follow this checklist in the order shown. Each step addresses one potential blocking layer. After each change, test the link with an external recipient before moving to the next step.
- Check the tenant-level external sharing policy
Go to the Microsoft 365 admin center at admin.microsoft.com. Select Settings > Org settings > SharePoint. Under Sharing, look at the external sharing setting. For client projects, it should be set to Anyone or New and existing guests. The Anyone option allows links that do not require sign-in. The New and existing guests option requires recipients to sign in with a Microsoft account or work account. If the setting is Only people in your organization, change it to one of the other two options. Click Save. - Check the OneDrive-level sharing setting
Go to the OneDrive admin center at admin.onedrive.com. Select Sharing on the left menu. Under External sharing, verify that the setting is not Only people in your organization. For client projects, choose Anyone or New and existing guests. Also set the default link type to Anyone with the link if you want minimal friction. Click Save. - Verify the link configuration on the shared file
Instruct the user who created the link to open the file in OneDrive and click Share. In the sharing dialog, click the gear icon or link settings. The link type must be Anyone with the link or People in your organization with the Allow editing checkbox selected if needed. If the link is set to Specific people and the external recipient is not listed, access will be denied. Change the link type and click Apply. Then send a new link to the client. - Check domain allow and block lists
In the Microsoft 365 admin center, go to Settings > Org settings > SharePoint. Under Sharing, expand Limit external sharing using domains. If a block list is enabled and the client’s email domain is listed, remove it. If an allow list is enabled and the client’s domain is not listed, add it. Click Save. - Review Azure AD conditional access policies
Go to the Azure AD admin center at aad.portal.azure.com. Select Security > Conditional Access. Look for any policies that target All cloud apps or Office 365 SharePoint Online and have a condition for Locations or Client apps. If a policy requires the user to be on a trusted IP range or a compliant device, external recipients may be blocked. Either exempt the guest user from that policy or adjust the conditions. Test the link again. - Check file type restrictions
In the SharePoint admin center at admin.sharepoint.com, select Policies > Sharing. Under File and folder links, look for blocked file types. If the shared file extension is on the blocked list, remove it or choose a different file format. Click Save. - Verify the recipient can access the link
Ask the external recipient to open the link in a private or incognito browser window. This eliminates issues caused by cached credentials. If the link requires sign-in, the recipient must use a Microsoft account or a work account that matches the domain allowed in step 4. If the link is set to Anyone, no sign-in is needed.
If External Links Still Show Access Denied
The link was created with an expiration date that has passed
Open the file in OneDrive, click the Share button, and then click Manage access. Look at the link expiration column. If the link has expired, delete it and create a new link with an expiration date far enough in the future. For client projects, consider setting no expiration or a date that covers the project timeline.
The external recipient sees a blank page instead of the file
This usually happens when the link points to a folder that contains files with blocked extensions. Check the folder contents for any file types that are blocked at the tenant level. Also verify that the user who shared the folder has not removed the recipient from the folder’s access list after creating the link. Ask the user to re-share the folder.
The OneDrive user account is disabled or deleted
If the user who shared the file leaves the organization or has their account disabled, all their sharing links stop working. To restore access, a different user with access to the same content must create a new sharing link. As a preventive measure, consider using SharePoint team sites for client projects instead of individual OneDrive accounts. SharePoint sites allow sharing to continue even if a site member leaves.
External Sharing Link Types: Comparison for Client Projects
| Item | Anyone with the link | People in your organization | Specific people |
|---|---|---|---|
| Authentication required | None | Microsoft 365 work or school account | Microsoft account or work account |
| Best for client projects | Yes, when recipients do not have Microsoft accounts | No, blocks external recipients | Yes, when you want to track who accesses the file |
| Can set expiration | Yes | Yes | Yes |
| Can set password | Yes | No | No |
| Works with conditional access | No, bypasses CA policies | Yes, subject to CA policies | Yes, subject to CA policies |
After completing the checklist, you can now identify and resolve Access Denied errors on external OneDrive links for client projects. Start by verifying the tenant and OneDrive sharing policies, then check the link configuration and domain restrictions. For ongoing projects, use the Anyone link type with a password and expiration to balance security and ease of access.