Troubleshooting Cross-Domain Shared Drive Access Errors

When external contractors, partner organizations, or subsidiaries attempt to access a Google Shared Drive, Google Drive frequently blocks the connection with errors such as “Access denied,” “This organization does not allow sharing with external accounts,” or “Action not permitted.” These failures indicate a policy mismatch between the two Google Workspace domains. Resolving cross-domain access requires auditing administrator policies, Trust Rules, and individual drive parameters across both the sharing and receiving organizations.

Quick Answer

Cross-domain Shared Drive access fails when either the host domain blocks outbound sharing, the recipient’s domain blocks inbound external collaboration, or the organizations do not share a reciprocal Google Workspace Trust Rule. To fix this, both domain administrators must add the partner domain to their allowlist or configure matching Trust Rules in the Google Admin Console.


The Dual-Tenant Architecture of Cross-Domain Sharing

Accessing a Shared Drive from outside an organization requires passing through security gates in both the host (sharing) tenant and the guest (receiving) tenant. If either domain enforces a block, the user is denied access:

Cross-Domain Access Flow:
[Tenant A: Host Organization]                 [Tenant B: Guest User]
  ├── Admin Sharing Policy = Allowed             ├── Admin Inbound Policy = Allowed
  ├── Trust Rule = Approved Tenant B    ◄──►     ├── Trust Rule = Approved Tenant A
  └── Shared Drive Settings = External ON        └── User Account in Active State
                         ▲                                     ▲
                         └──────────────┬──────────────────────┘
                                        │
                        [Access Handshake Evaluated]
                         ├── Both Domains Allow? ──> ACCESS GRANTED
                         └── Either Domain Rejects? ──> 403 ACCESS DENIED

A common misconception is that the host organization holds exclusive control. Even if the host enables external sharing, an external user will still receive access errors if their own company administrator restricts inbound sharing.


Primary Causes of Cross-Domain Failures

1. Host Domain Blocks Outbound Sharing

The host organization may restrict external sharing globally or at the Organizational Unit (OU) level. If the host administrator restricts Drive sharing to internal users only, external email addresses cannot be added as Shared Drive members or sent direct links. For domain-level policy instructions, see Why Shared Drive External Sharing is Blocked.

2. Recipient Domain Blocks Inbound External Collaboration

Many enterprise Google Workspace tenants enforce inbound data-loss prevention (DLP) rules. These settings prevent company employees from logging into or viewing external Google Drive resources to prevent unauthorized data exfiltration. If a contractor using user@contractor.com cannot view your Shared Drive, their IT team may have blocked access to outside drives.

3. Google Workspace Trust Rules Conflict

Modern Google Workspace editions (Enterprise and Education) use Trust Rules instead of basic allowlists. Trust Rules provide granular control over cross-domain actions:

  • Inbound sharing: Governs whether internal users can receive files from outside.
  • Outbound sharing: Governs whether internal users can share with specific external domains.
  • If Tenant A creates an outbound Trust Rule allowing Tenant B, but Tenant B does not have a corresponding inbound Trust Rule allowing Tenant A, file access fails.

4. Drive-Level Non-Member Restrictions

Even when both domains permit cross-domain collaboration, the specific Shared Drive may have local restrictions enabled. If the drive has the setting “Prevent people who aren’t shared drive members from accessing files” toggled on, external users cannot access individual files via direct links. For operational workarounds, review Why “Prevent non-members from accessing files” is breaking flow.


Diagnostic Checklist & Step-by-Step Resolution

Step 1: Verify Host Shared Drive Settings

A user with the Manager role must confirm that the target Shared Drive permits external users:

  1. Open Google Drive and navigate to Shared drives.
  2. Select the Shared Drive, click the Settings (gear) icon in the upper-right corner, and open Shared drive settings.
  3. Verify that Allow people outside [Organization] to access files is checked.
  4. If this checkbox is grayed out, external sharing is disabled by an administrator policy; see Fix: “User is not in the required Organizational Unit”.

Step 2: Audit Host Domain Sharing Policies (Google Admin Console)

A Google Workspace administrator in the host organization must inspect sharing rules:

  1. Sign in to the Google Admin Console.
  2. Go to Apps > Google Workspace > Drive and Docs > Sharing settings.
  3. Under Sharing outside of [Organization], check the policy applied to the OU containing the Shared Drive:
    • If set to OFF, external sharing is completely disabled.
    • If set to Allowlisted Domains, verify that the recipient’s domain (e.g., partner.com) is explicitly listed.

Step 3: Check Trust Rules Configuration

If your tenant uses Trust Rules rather than standard allowlists:

  1. In the Admin Console, go to Security > Access and data control > Trust rules.
  2. Review rules applied to Drive:
    • Confirm that an Outbound Sharing rule exists targeting the recipient domain with the action set to Allow.
    • Confirm that the rule applies to the Organizational Unit housing the project.

Step 4: Validate Recipient Domain Inbound Access

If all host settings are verified but the guest user still receives an access error:

  1. Ask the external collaborator to attempt access while signed into their personal @gmail.com account (if permitted by your company policy). If personal accounts can access the drive while their corporate account cannot, their organization’s inbound policy is enforcing the block.
  2. The external user must contact their IT administrator to add your company domain to their inbound Trust Rules or allowlist.

Next Steps for Complex Collaboration

If policies are configured correctly but users still encounter permission loops: