Teams 1:1 Chat with External Guest: Drag-and-drop file sharing fails with "Access Denied" unless permissions are manually applied

Question

Teams 1:1 Chat with External Guest: Drag-and-drop file sharing fails with "Access Denied" unless permissions are manually applied

Stepan 0

Hello

I am experiencing a consistent issue with file sharing in 1:1 Microsoft Teams chats with external guest users.

Issue Description: When I drag and drop a file into a 1:1 chat with a guest user (who is properly added as a B2B guest in our Entra ID), the guest receives an "Access Denied" error when trying to open the file via the generated SharePoint/OneDrive link. However, if I attach the file, click on the sharing permission text (which defaults to "People currently in this chat"), and manually click "Apply" before sending the message, the file opens perfectly for the guest.

Troubleshooting already performed:

Tenant-level SharePoint and OneDrive sharing policies are set to "Anyone" (Most Permissive).

My personal OneDrive external sharing is fully enabled.

The "Limited-access user permission lockdown mode" in Site Collection Features is deactivated.

Default sharing link in SharePoint Admin Center is set to "Specific people" (we also tested "Anyone" with no success).

Question: Since all external sharing policies are correctly configured, why does the automatic background permission assignment fail for B2B guests in 1:1 chats upon drag-and-drop? Is this a known bug with the current Teams/OneDrive integration, or is there another hidden setting (perhaps in Purview/DLP) preventing automatic permission generation?

Best regards [Moderator note: Personally Identifiable Information removed]

0 comments

2 answers

Your answer

Answer 1

Dear @Stepan,

Good day, and I appreciate the clear explanation of your concern. From my research, file sharing in external chats in Microsoft Teams behaves as follows: while uploading or dragging files into the chat is supported, external recipients may not automatically have access to those files. In such cases, senders may need to manually adjust permissions. This behavior often depends on the configuration of messaging policies and sharing settings.

Because of this, the behavior you’re observing appears to be consistent with the current documented behavior, even though it may not feel ideal from an operational perspective.

I recommend checking whether the AutoShareFilesInExternalChats setting is disabled in the messaging policy assigned to you or your users. If automatic sharing is turned off, users will need to manually grant access to shared files. This setting can be managed via PowerShell.

While reviewing this, I did not find clear documentation confirming that Purview DLP specifically causes this exact permission issue with drag-and-drop scenarios. However, other controls such as sensitivity labels, domain restrictions, or safe link protections can still affect external file access. These are more likely factors to investigate, especially if the file uploads successfully but the external recipient cannot open it.

For reference: Share files and Loop in external chats - Microsoft Teams | Microsoft Learn

For further insight, I recommend that the Global Administrator in your organization create a service request with Microsoft Support. A technical support engineer can then investigate the issue in detail, review backend configurations, and perform any necessary checks. If needed, the case can also be escalated to a specialized team for deeper analysis. For detailed instructions on how to get support, please refer to Get support - Microsoft 365 admin. If you don't know who your IT administrator is, please refer to this article: How do I find my Microsoft 365 admin? - Microsoft Support

I hope this information is helpful. Please feel free to let me know if you need any further assistance. Wishing you all the best, and I hope everything works smoothly moving forward.

If the answer is helpful, please click "Accept Answer" and kindly upvote it.

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.

Stepan 0 Reputation points

2026-05-20T06:19:28.12+00:00

I have run the recommended command, and I can confirm that the AutoShareFilesInExternalChats property is already set to Enabled.

Here is the exact output from my PowerShell session:

Identity: Global

AutoShareFilesInExternalChats: Enabled
Kai-L 18,970 Reputation points Microsoft External Staff Moderator

2026-05-20T16:04:22.59+00:00

Dear @Stepan,

Thank you for your update.

Since AutoShareFilesInExternalChats is already set to Enabled at the Global level, this confirms that automatic sharing is not being restricted by that specific policy, which helps narrow down the scope of the issue.

At this point, the behavior is more likely influenced by other configurations or controls, such as:

Sensitivity labels or protection policies applied to the file

Domain or conditional access restrictions

Safe Links or other security policies affecting external access

If the file uploads successfully but external users still cannot access it without manual permission changes, it often indicates that another layer of policy is affecting the sharing behavior.

As a forum moderator, I want to note that I do not have visibility into your tenant configuration or backend policy setup. Because of that, I can only help narrow the issue down based on the information you are able to verify and share from your side.

Based on your testing so far, this may require a deeper configuration review. I recommend that your Global Administrator open a support request so Microsoft Support engineer can review the backend configuration in detail and provide a more targeted resolution. You may refer to my previous response for steps on how to contact support.

Thank you again for your thorough testing and cooperation. Please let me know if you need any further assistance, I’ll be happy to help where I can. Wishing you all the best.

Answer 2

The behavior described is consistent with how Teams, OneDrive, and SharePoint enforce sharing and access control, and with known limitations around external/guest access and link types.

From the provided information, there are two relevant mechanics:

Limited-access user permission lockdown mode
- When this site collection feature is enabled, it restricts how users (especially external/anonymous) can access content via application pages and links. It is explicitly called out as a cause of access issues for files shared through Teams and OneDrive.
- For Teams/OneDrive scenarios, this feature is not recommended because it can block access to files shared via links, including those generated in Teams chats.
- The documented fix for similar “You don't have access to this file” errors in Teams is to deactivate this feature on the OneDrive site:
  1. Sign into the OneDrive site.
  2. Go to Settings → OneDrive Settings → More Settings.
  3. Under Features and storage, select Site Collection Features.
  4. Deactivate Limited-access user permission lockdown mode.
Link type and large/complex sharing scenarios
- Teams file sharing in chat uses SharePoint/OneDrive link types such as Specific people (which corresponds to “People currently in this chat”).
- Documentation notes that when Specific people links are used in larger chats (more than 100 participants), some users may not automatically receive permissions and must request access. This illustrates that automatic permission assignment for certain link types is not guaranteed to succeed for all participants in all scenarios.

In the scenario described:

When the file is dragged and dropped, Teams automatically creates a link and attempts to assign permissions in the background.
When the sharing control is explicitly opened and Apply is clicked before sending, the link and permissions are explicitly re-evaluated and applied, which succeeds for the guest.

This aligns with the documented behavior where:

Access issues can occur when site-level features (such as Limited-access user permission lockdown mode) interfere with link-based access.
Automatic link/permission assignment for certain link types and participant combinations (including guests) can fail, requiring manual adjustment.

The documentation provided does not identify this as a specific “bug” in Teams, nor does it reference a Purview/DLP setting as the cause. Instead, it attributes similar access-denied issues to:

The Limited-access user permission lockdown mode feature being enabled on OneDrive/SharePoint.
The way Specific people links behave in larger or more complex sharing scenarios.

Given the context, the recommended actions are:

Confirm again that Limited-access user permission lockdown mode is deactivated on the specific OneDrive site that stores the chat files (not just at a generic level).
Ensure that external sharing settings remain configured as documented in the SharePoint and Microsoft 365 guest sharing references.
Continue using the explicit Apply step as a reliable workaround when sharing with guests, as this forces the correct link and permission assignment.

The available documentation does not expose any additional hidden setting (such as a Purview/DLP toggle) that specifically controls this drag-and-drop background permission assignment for B2B guests.

References: