Hi @PNC,

Thanks for checking... 

I think your setup is very close. The missing piece is which identity is actually used for the MV backing storage, which is not necessarily the same as the one behind your external location.

Because you’re already seeing a 403 from ADLS for the __unitystorage path, the serverless MV pipeline is actually starting, which is good. The failure is now purely an Azure Storage authorisation problem, not a serverless problem.

SELECT COUNT(*) FROM catalog.schema.table reads from your external location abfss://my-container@my-storage-account.dfs.core.windows.net/catalog using storage credential my_credential (backed by my-access-connector), which has Blob Data Contributor. So, it works.

Your create MV query writes MV data under the schema’s managed location (.../catalog/schema/__unitystorage/schemas/...).

The serverless MV pipeline uses the identity associated with the catalog/schema’s managed storage / metastore default storage, which may be different from my_credential.

So you’ve granted rights to my-access-connector (for the external location), but the identity actually used for __unitystorage/... is likely another access connector or managed identity that currently does not have rights on my-storage-account, hence the 403.

Can you find which credential is used for the managed location

You can do this by querying as shown below...

DESCRIBE CATALOG EXTENDED catalog;
DESCRIBE SCHEMA EXTENDED catalog.schema;

You’re looking for the storage credential name (and thus the access connector / identity) that backs the managed location where __unitystorage/schemas/... lives. It may not be my_credential.

In the Databricks account console, open the storage credential you found in above step and note its access connector / managed identity.

In the Azure Portal... Go to storage account my-storage-account --> Access control (IAM). Add a role assignment as below..

• Role: Storage Blob Data Contributor (or Owner)
• Scope: the storage account (or at least my-container)
• Principal: the identity from that storage credential (not just my-access-connector if they differ).

After correcting storage permissions for the actual managed-location identity, rerun the below to see if it works

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.mView_test
AS SELECT * FROM catalog.schema.table LIMIT 10;