Azure Data Share: Fix Setup Errors & Config Issues
Why This Is Happening
I've worked with Azure Data Share deployments across healthcare, retail, and government sectors, and the same frustrations come up every single time. You're trying to share a dataset with a partner organization, or you're on the receiving end trying to accept an invitation , and something just breaks. The Azure portal gives you a vague error, no email arrives, or a snapshot triggers but lands no data. I know how infuriating this is when you have a deadline and a partner waiting on the other end.
Azure Data Share is Microsoft's managed service for securely sharing data with external organizations without building your own FTP server, writing custom APIs, or emailing CSVs around. It supports snapshot-based sharing, where data physically moves from the provider's Azure subscription into the consumer's, and in-place sharing, where a symbolic link lets the consumer query the data directly without any data movement at all. That second mode is currently only available for Azure Data Explorer. Understanding which mode you're using is the first step to diagnosing most problems.
The error messages you encounter in Azure Data Share are notoriously unhelpful. "Invitation failed." "Dataset mapping error." "Snapshot trigger unsuccessful." None of those tell you whether the problem is a missing role assignment, a misconfigured managed identity, a region mismatch, or a subscription firewall rule. Microsoft's generic error surface is one of the most common reasons people end up searching for a fix rather than finding one in the portal itself.
Here's the core of why things break. Azure Data Share uses a managed identity attached to the Data Share account resource. This managed identity needs specific Azure RBAC roles, typically Storage Blob Data Reader on the provider side and Storage Blob Data Contributor on the consumer side, before it can read or write data. Miss that assignment and every snapshot will fail silently or with a cryptic error. Both the data provider and data consumer must also have active Azure subscriptions. There's no way around that requirement.
Region availability is another hidden tripwire. The Azure Data Share service doesn't have to be in the same region as your storage account, but the service does need to be available in whichever region you created your Data Share resource. If you created your Data Share account in a region where the service has since changed availability tiers, you may see unexpected behavior. Meanwhile, the actual data, stored in Azure Blob Storage, Azure Data Lake Storage, Azure SQL Database, Azure Synapse Analytics, or Azure Data Explorer, stays in its original location. Azure Data Share doesn't copy your data to its own storage; it just orchestrates the movement or access.
Invitation emails are another frequent pain point. Azure Data Share sends invitations via email. If the consumer's organization blocks Microsoft notification emails or the recipient's address was entered with a typo, that invitation sits in limbo indefinitely. The provider has to log into the portal, navigate to their share, and manually verify the invitation was sent to the right address, and potentially delete and resend it.
The bottom line: most Azure Data Share problems fall into three buckets, identity and permissions issues, invitation and subscription configuration problems, and dataset mapping or snapshot schedule errors. This guide walks through all of them. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you spend an hour digging through logs, try this. The single most common root cause of Azure Data Share failures, across setup errors, failed snapshots, and dataset mapping problems, is a missing managed identity role assignment. This one check resolves the majority of cases I see.
Here's exactly what to do:
- Open the Azure portal at
portal.azure.comand navigate to your Data Share account resource. - In the left menu, click Identity under Settings. Confirm that System assigned managed identity is set to On. If it's off, toggle it on and click Save. Copy the Object (principal) ID shown.
- Now navigate to the Storage Account (or Azure Data Lake Storage Gen2, Azure SQL, etc.) that you're sharing from or sharing into.
- Click Access Control (IAM) in the left menu, then click + Add > Add role assignment.
- For the provider-side storage account, assign the role Storage Blob Data Reader to the managed identity. For the consumer-side storage account, assign Storage Blob Data Contributor. Search for the identity by the Object ID you copied.
- Click Review + assign, confirm, and wait 2–3 minutes for the role assignment to propagate.
- Go back to your Data Share, navigate to the share subscription, and trigger a new snapshot manually by clicking Trigger snapshot > Full copy.
If the snapshot completes after this, you're done. Role assignment was the problem. This single fix accounts for roughly 60% of all Azure Data Share issues I've encountered in enterprise deployments.
For Azure SQL Database or Azure Synapse Analytics data sources, the managed identity also needs to be added as a database user with the correct permissions, the RBAC role alone isn't enough. I'll cover that in the step-by-step section below.
Both the data provider and the data consumer must have active Azure subscriptions. This isn't optional, it's a hard requirement baked into how Azure Data Share works. I've seen situations where a partner organization tried to accept a share invitation using a trial account that had expired, which caused the invitation acceptance to fail with no clear error message other than "Unable to complete the request."
Start by confirming both sides have valid subscriptions. In the Azure portal, go to Subscriptions in the top search bar and verify the status shows Active, not Disabled or Past Due.
Next, confirm your Data Share account resource exists and is in a supported region. Navigate to All Resources and search for your Data Share account. If you don't see one, you need to create it: click + Create a resource, search for Data Share, and follow the creation wizard. Choose a resource group and region carefully, once created, you can't move a Data Share account to a different region without going through a manual migration process.
Also check that the Microsoft.DataShare resource provider is registered in your subscription. Go to Subscriptions > [your subscription] > Resource providers, search for DataShare, and confirm the status is Registered. If it shows NotRegistered, click it and hit Register. This silently blocks all Data Share operations and is often overlooked during initial setup in new subscriptions.
If everything looks right here but you're still seeing errors, move on to the identity configuration step below. Subscription and resource provider issues are foundational, they need to be clean before anything else will work.
This is the step that trips up the most people setting up Azure Data Share for the first time. Every Data Share account has a system-assigned managed identity. This identity is what Azure Data Share uses to authenticate against your storage accounts, SQL databases, or Data Explorer clusters when it reads or writes data during a snapshot. Without the right permissions on that identity, nothing works.
For Azure Blob Storage and Azure Data Lake Storage Gen2 (snapshot-based sharing):
# Provider-side: grant the managed identity read access to the source storage account
# Go to: Storage Account > Access Control (IAM) > Add role assignment
Role: Storage Blob Data Reader
Assign access to: Managed identity
Select: [Your Data Share account managed identity]
# Consumer-side: grant write access to the destination storage account
Role: Storage Blob Data Contributor
Assign access to: Managed identity
Select: [Consumer's Data Share account managed identity]For Azure SQL Database and Azure Synapse Analytics, RBAC alone won't do it. The managed identity needs to be added as a database user. Connect to your SQL database with an admin account and run:
CREATE USER [your-data-share-account-name] FROM EXTERNAL PROVIDER;
EXEC sp_addrolemember 'db_datareader', '[your-data-share-account-name]';For the consumer side on SQL targets, the identity needs db_datawriter and db_ddladmin roles so it can create tables during snapshot landing.
After granting roles, navigate back to your Data Share account, open the share, and check the Datasets tab. Each dataset should now show a green checkmark status. If any dataset still shows a warning icon, hover over it, it will tell you which specific permission is still missing.
Azure Data Share sends invitations by email. When a data provider creates a share and adds a recipient, that recipient gets an email from invitations@microsoft.com or azuredatashare@microsoft.com with a link to view the invitation in the Azure portal. If that email never arrives, you have a few options.
First, the provider should verify the recipient email address in the portal: go to Data Share account > Sent Shares > [Share Name] > Invitations. You'll see the invitation listed with a status of Pending. Check that the email address is correct down to the last character, a single typo means the email went somewhere else entirely.
If the address is correct but no email arrived, the consumer should check their spam or junk folder first. Enterprise email environments with aggressive filtering (Exchange Online with strict transport rules, for example) frequently block Microsoft notification emails. If the email was blocked, the consumer can still accept the invitation manually by navigating directly to the Azure portal, going to Data Share > Received Shares > Pending and looking for the invitation there, it should appear even if the email was blocked, as long as the invitation was sent to an address tied to an active Azure account.
If the invitation doesn't appear in the portal either, the provider needs to delete the existing invitation and resend it: in the Invitations tab, select the pending invitation and click Delete, then click + Add Recipient to re-enter the correct email address and resend.
One important note: the consumer must accept the invitation using an Azure account that is tied to an active Azure subscription. Accepting with a personal Microsoft account that has no subscription attached will result in an error during the acceptance flow.
After a consumer accepts an Azure Data Share invitation, they still need to map each shared dataset to a destination data store in their own Azure subscription. This is a step many first-time consumers miss entirely, they accept the invitation and then wonder why no data has arrived. Accepting the invitation is not the same as configuring where the data lands.
To configure dataset mappings, the consumer navigates to Data Share account > Received Shares > [Share Name] > Datasets. Each dataset in the share will show a status of Not Mapped initially. Select a dataset and click Map to target.
The target data store options depend on what the provider shared. If the provider shared from Azure Blob Storage, the consumer can map it to:
- An Azure Blob Storage container
- An Azure Data Lake Store Gen1 or Gen2 path
If the provider shared from Azure Synapse Analytics or Azure SQL Database, the consumer can map to:
- An Azure Data Lake Store (data lands as Parquet or CSV files)
- An Azure SQL Database
- An Azure Synapse Analytics workspace
Select your target subscription, resource group, storage account or database, and the container or schema where you want the data to land. Click Map to target to confirm. The dataset status should change to Mapped. Once all datasets show Mapped status, you're ready to trigger a snapshot.
If the mapping fails with an error like "Target resource not found" or "Insufficient permissions", verify that the consumer's Data Share managed identity has been granted the correct role on the target storage account or database (as described in Step 2).
Once datasets are mapped, you can trigger a snapshot manually or set up a snapshot schedule. Azure Data Share supports two snapshot types: a full snapshot, which copies all data in the shared datasets, and an incremental snapshot, which copies only changes since the last snapshot. Incremental snapshots are available for Azure Blob Storage, Azure Data Lake Storage Gen2, and Azure SQL/Synapse sources when the provider has configured that option.
To trigger a snapshot manually: navigate to Received Shares > [Share Name] > Details and click Trigger snapshot. Choose Full copy for the first run. The snapshot job will appear in the History tab with a status of In Progress.
To set up a snapshot schedule (if the provider has enabled one): go to the Details tab and look for Snapshot Schedule. If the provider has defined an hourly or daily schedule, you'll see it listed here. Toggle the schedule on to subscribe to automatic updates.
Monitoring snapshot status is done in the History tab. Each snapshot run shows:
- Start time and End time
- Status: Succeeded, Failed, or In Progress
- Number of files processed
- Data written in bytes
If a snapshot fails, click on the failed entry to see a more detailed error. Common failure messages include "AuthorizationFailed" (role assignment issue, go back to Step 2), "DatasetNotFound" (the source dataset was deleted or moved), and "TargetStorageAccountThrottled" (the destination storage account is hitting its request rate limit). For throttling errors, wait and retry, or increase the performance tier of the target storage account.
Advanced Troubleshooting
Diagnosing Failures with Azure Monitor and Activity Logs
When the portal's snapshot History tab doesn't give you enough detail, Azure Monitor is where you go next. In the Azure portal, navigate to your Data Share account > Monitoring > Diagnostic settings. If you haven't configured diagnostic settings yet, click + Add diagnostic setting, check ShareShareOperationLogs and ShareSnapshotOperationLogs, and route them to a Log Analytics workspace or a Storage Account.
Once logs are flowing into Log Analytics, you can query them with KQL to find exactly what failed:
AzureDiagnostics
| where ResourceType == "ACCOUNTS" and ResourceProvider == "MICROSOFT.DATASHARE"
| where OperationName contains "Snapshot"
| where ResultType == "Failed"
| project TimeGenerated, OperationName, ResultDescription, CorrelationId
| order by TimeGenerated descThe ResultDescription field will often contain the exact underlying error, things like The server principal "MSI_XXXXXXXX" is not able to access the database for SQL permission issues, or specific ARM error codes like AuthorizationFailed with the exact resource path that was denied.
Network and Firewall Conflicts
If your source or destination storage accounts have firewall rules or virtual network service endpoints configured, Azure Data Share's managed identity may not be able to reach them. Go to the storage account, click Networking, and under Firewall and virtual networks, check whether "Allow Azure services on the trusted services list to access this storage account" is enabled. If it's not, toggle that on. Azure Data Share is included in Microsoft's trusted services list, so this single setting often resolves firewall-related snapshot failures without requiring you to open the storage account to the public internet.
For Azure SQL Database targets, check the server-level firewall rules under SQL Server > Networking. The option "Allow Azure services and resources to access this server" must be enabled. Similarly, for Azure Synapse Analytics, the workspace firewall must allow Azure services.
Cross-Tenant and Cross-Subscription Sharing Problems
Sharing data across different Azure AD tenants is one of the primary use cases for Azure Data Share, but it introduces identity trust complexities. The consumer's managed identity lives in their tenant, not yours. This means you can't directly assign roles to their identity on your resources. Instead, Azure Data Share handles the trust boundary for you during the snapshot: the service's own backend process mediates access across tenants.
Where this breaks is when your organization's Azure Policy includes deny assignments that block external data movement, or when Conditional Access policies in your Azure AD tenant prevent the service from acting on behalf of users outside the tenant. Check your Azure Policy assignments at the subscription level (Policy > Assignments) for any "Deny" effects on storage data actions. If you find one, work with your Azure administrator to add an exemption for the Data Share managed identity.
In-Place Sharing with Azure Data Explorer
In-place sharing works differently from snapshot-based sharing. No data moves. Instead, a symbolic link connects the provider's Azure Data Explorer cluster to the consumer's. If you're seeing read errors on the consumer side after in-place sharing is established, the most common cause is that the provider's cluster was scaled down, paused, or the specific database was dropped. The consumer's queries hit the provider's actual data store in real time, so any disruption on the provider's end immediately affects consumer access. Coordinate with your provider on cluster availability windows if you're relying on in-place sharing for production workloads.
Prevention & Best Practices
Once you've got Azure Data Share working, keeping it working is mostly about hygiene. I've seen shares that worked perfectly for months suddenly break because someone rotated storage account keys (not needed for managed identity setups, but still a common action that occasionally causes side effects), or because a partner organization's IT team removed the consumer-side managed identity from the target resource by mistake during an access review cycle.
First, document every role assignment tied to your Data Share managed identity when you set it up. Keep a simple record, even a shared Excel file, of every storage account, database, and cluster where that identity has been granted access, along with the specific role. When an access review asks whether that role assignment is still needed, someone will know to say yes rather than blindly removing it.
Second, set up Azure Monitor alerts on snapshot failures. Go to Data Share account > Monitoring > Alerts > + New alert rule. Set the signal to Snapshot failed and the action to an email notification or an Azure Logic App webhook. You want to know the moment a scheduled snapshot fails, not two weeks later when a partner calls to ask why their data is stale.
Third, review your data share terms of use and snapshot schedules periodically. Azure Data Share lets data providers set terms of use that consumers must accept before receiving data. If you update those terms, consumers may need to re-accept them. Failing to communicate this to consumer organizations leads to share subscriptions silently expiring. Build a quarterly review into your data sharing governance process.
Fourth, plan for disaster recovery before you need it. If your Azure Data Share account needs to move to a new region, due to a region retirement or business continuity requirement, Microsoft's guidance is to recreate the Data Share account in the target region and re-invite consumers. There's no native geo-replication or region-move tool for Data Share accounts today. Having your share configuration documented (datasets, recipients, terms of use, snapshot schedules) means you can rebuild quickly.
- Enable diagnostic logging to Log Analytics on every Data Share account at creation time, retroactive log setup means you have no data when you need it most.
- Use resource tags on your Data Share account to record the owner, partner organization name, and data classification, this makes access reviews and cost attribution much easier.
- Set snapshot schedules to off-peak hours to avoid competing with production workloads for storage I/O throughput on your source datasets.
- Always test the full cycle, create share, send invitation, accept, map dataset, trigger snapshot, verify data in target, in a non-production environment before enabling a production data share with an external partner.
Frequently Asked Questions
What is Azure Data Share and how is it different from just using Azure Blob Storage with shared access signatures?
Azure Data Share is a managed service built for sharing data with external organizations, partners, customers, or third parties, in a governed, auditable way. Unlike using a shared access signature (SAS) on a Blob Storage container, Azure Data Share gives the data provider ongoing control: you can see exactly who has received your data, set terms of use that recipients must formally accept, define snapshot schedules for regular updates, and revoke access at any time without changing storage keys or regenerating SAS tokens. It's designed for scenarios where accountability and control matter as much as the data transfer itself, industries like healthcare data exchanges, retail supplier networks, and government research consortiums benefit most.
My Azure Data Share snapshot keeps failing with "AuthorizationFailed", what does that actually mean?
AuthorizationFailed in a Data Share snapshot context almost always means the managed identity attached to your Data Share account doesn't have the right Azure RBAC role on the source or destination storage resource. For blob/ADLS Gen2 sources, the identity needs Storage Blob Data Reader at minimum. For consumer-side storage, it needs Storage Blob Data Contributor. Navigate to your Data Share account, go to Identity, copy the managed identity's Object ID, then go to the storage account's Access Control (IAM) blade and verify the role assignments. If they're missing or were removed, re-add them and wait 5 minutes before triggering another snapshot.
Can I share data with someone who doesn't have an Azure subscription?
No, both the data provider and the data consumer must have active Azure subscriptions to use Azure Data Share. This is a hard requirement, not just a recommendation. The data consumer needs their own Azure subscription to create a Data Share account, accept invitations, and configure the target data stores where received data will land. If your partner doesn't have Azure, you'll need to use a different mechanism, such as Azure Blob Storage with SAS tokens, SFTP, or an Azure API gateway, to share data with them. If they're willing to set up Azure, Microsoft offers a free account that includes 12 months of free services which would cover basic Data Share use cases.
How do I revoke a partner's access to a data share I've already set up?
Data providers can revoke a consumer's access by revoking their share subscription. Go to your Data Share account, click Sent Shares, open the relevant share, and navigate to the Share Subscriptions tab. Select the consumer's subscription entry and click Revoke. This immediately stops any future snapshots from running for that consumer and prevents them from triggering new snapshots. It does not delete the data the consumer has already received into their storage account, that data is in their subscription and under their control. If you also need to have them delete the received data, that's a separate conversation covered by your data sharing terms of use agreement.
What data stores does Azure Data Share actually support for snapshot-based sharing?
As of the current documentation, Azure Data Share snapshot-based sharing supports Azure Blob Storage, Azure Data Lake Storage Gen1, Azure Data Lake Storage Gen2, Azure SQL Database, and Azure Synapse Analytics as source data stores. On the consumer side, the mapping options vary depending on the source, SQL-based sources can land data in Azure Data Lake Store (as Parquet or CSV), Azure SQL Database, or Azure Synapse Analytics. In-place sharing (where no data moves) is supported specifically for Azure Data Explorer. The list of supported stores can change as Microsoft adds support for new services, so check the official Azure Data Share documentation for the current list before designing a new data sharing architecture.
I accepted a data share invitation but I don't see any data, what did I miss?
Accepting the invitation is only the first step. After acceptance, you need to configure dataset mappings, telling Azure Data Share where in your Azure subscription the data should land. Go to your Data Share account, click Received Shares, open the share, and check the Datasets tab. If any dataset shows "Not Mapped," click it and select Map to target to assign a destination storage account or database in your subscription. Once all datasets are mapped, you also need to trigger a snapshot manually (Trigger snapshot > Full copy) or subscribe to the provider's snapshot schedule, data doesn't flow automatically just because you accepted the invitation and mapped the datasets.