Forum Discussion
Materialized Views in Mirrored Azure Databricks Catalog not working
Memorable MemberHi carlhsg,
I can't reproduce this, so what follows is a way to narrow it down rather than a confirmed cause. Your description gives a strong clue: the same service principal, the same workspace resource instance rule and the same Blob Read role work for regular Delta tables behind the firewall, but not for materialized views, and the Monitor Catalog page still reports the views as successful. That points at the data location rather than at permissions on the catalog.
My working hypothesis
A materialized view is not necessarily stored in the same account, container or path as the external tables you already opened up. If its data lives in a different location (for example a managed storage location for the catalog or schema), then the firewall exemption and the role assignment you created would not cover it. Listing succeeds because that is a metadata operation, while reading the files fails, which matches a preview pane that cannot load.
-- In Azure Databricks: where does the materialized view actually keep its data?
DESCRIBE EXTENDED my_catalog.my_schema.my_materialized_view;
-- Compare the Location with the storage account and container
-- that your firewall rule and the RBAC assignment cover.Checks to run
| Check | What to compare | If it differs |
|---|---|---|
| Storage location of the view | The location shown by the describe command versus the account and container in your resource instance rule | Add the workspace to the firewall rules of that account, and grant the read role on that container too |
| RBAC scope | Role assignment on the container or account that holds the view data, not only the table container | Assign the read role at the scope that covers both |
| Which identity reads the files | Whether the Fabric side uses the workspace identity or the service principal for the storage path | Make sure the identity that reads files has the role and is allowed through the firewall |
| Same behavior with a regular table in the same schema | Whether a table stored in the view location also fails | Confirms the location, not the object type, is the problem |
| Region and network path | Fabric capacity region versus storage region, and any private endpoint requirements | Check the trusted workspace access prerequisites for your setup |
What to collect if it still fails
- The exact error from the SQL analytics endpoint and the preview pane, with timestamps.
- The storage account diagnostic logs for the failed read: a denied request shows which identity and which path was refused.
- The describe output for one working table and one materialized view side by side.
The storage account logs are the quickest way to turn this from a guess into a fact, since a firewall block and a missing role look different in the log. If the logs show the request never arrives, the network rule is the issue; if it arrives and is denied, the role assignment is.
So my overall approach would be:
1. Find where the materialized view stores its data
2. Make sure the firewall rule and read role cover that exact location
3. Compare with a regular table stored in the same place
4. Use storage diagnostic logs to see whether the block is network or role
5. If it persists, open a support case with the logs and both describe outputsAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Appreciate the detailed response.
The MVs are in the same storage account, container and directory as the delta tables which can be mirrored successfully (managed unity storage).
When reviewing the storage logs I did find an interesting difference between the successful reads of delta tables and unsuccessful MVs. There are authentication errors for the request to the storage files for MVs with "DelegationSAS" whereas with delta the request are successful OAuth. So there seems to be different authentication methods.
