MLflow Unity Catalog Trace Location Fails with Zerobus PERMISSION_DENIED for Private Endpoint-backed UC Storage

Question

MLflow Unity Catalog Trace Location Fails with Zerobus PERMISSION_DENIED for Private Endpoint-backed UC Storage

Fred Catameo 46

When attempting to create an MLflow3 experiment configured to store traces directly in Unity Catalog, Databricks MLflow Trace Storage validation through Zerobus continues to fail with a PERMISSION_DENIED error. The Unity Catalog storage account is secured via Azure Private Endpoints, and NCC connectivity for Databricks Serverless SQL Warehouses has already been configured and validated.

MLflow3 code to replicate:

https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/tracing/migrate-traces-to-uc

May we confirm if this is a known limitation? MLflow/Zerobus trace ingestion does not currently support Unity Catalog tables whose underlying storage is accessible only through Azure Private Endpoints.

Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-09-08T23:30:46.77+00:00

Hello @Fred Catameo ,

Thank you for reaching out to us

We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.

Thank you
Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-09-09T05:05:12.9933333+00:00

Hello @Fred Catameo ,

Thank you for providing the detailed information and reproduction steps.

We understand that you are attempting to configure MLflow 3 trace storage in Unity Catalog, but the trace storage validation through Zerobus is failing with a PERMISSION_DENIED error. We also understand that the Unity Catalog storage account is secured through Azure Private Endpoints and that NCC connectivity for Databricks Serverless SQL Warehouses has already been configured and validated.

Based on the information provided, the behavior appears to be related to the connectivity or access path used by MLflow/Zerobus to reach the underlying Unity Catalog storage. The successful NCC connectivity validation for Serverless SQL Warehouses does not necessarily confirm that the Zerobus service uses or supports the same network path.

We are currently reviewing whether MLflow/Zerobus trace ingestion supports Unity Catalog tables whose underlying storage is accessible exclusively through Azure Private Endpoints, and whether the PERMISSION_DENIED error is expected in this configuration.
Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-09-10T01:46:03.5533333+00:00

Hi @Fred Catameo
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

1 answer

Your answer

Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator

2026-09-08T23:30:46.77+00:00

Hello @Fred Catameo ,

Thank you for reaching out to us

We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.

Thank you
Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-09-09T05:05:12.9933333+00:00

Hello @Fred Catameo ,

Thank you for providing the detailed information and reproduction steps.

We understand that you are attempting to configure MLflow 3 trace storage in Unity Catalog, but the trace storage validation through Zerobus is failing with a PERMISSION_DENIED error. We also understand that the Unity Catalog storage account is secured through Azure Private Endpoints and that NCC connectivity for Databricks Serverless SQL Warehouses has already been configured and validated.

Based on the information provided, the behavior appears to be related to the connectivity or access path used by MLflow/Zerobus to reach the underlying Unity Catalog storage. The successful NCC connectivity validation for Serverless SQL Warehouses does not necessarily confirm that the Zerobus service uses or supports the same network path.

We are currently reviewing whether MLflow/Zerobus trace ingestion supports Unity Catalog tables whose underlying storage is accessible exclusively through Azure Private Endpoints, and whether the PERMISSION_DENIED error is expected in this configuration.
Pilladi Padma Sai Manisha 11,715 Reputation points Microsoft External Staff Moderator

2026-09-10T01:46:03.5533333+00:00

Hi @Fred Catameo
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

Answer 1

Yes. Based on the current Databricks documentation, this appears to be a known limitation of MLflow 3 trace storage in Unity Catalog, rather than an issue with Unity Catalog permissions, SQL Warehouse access, or Network Connectivity Configuration (NCC).

The documentation for storing OpenTelemetry traces in Unity Catalog explicitly states:

"Traces cannot yet be written to storage protected by Private Link." [docs.databricks.com]

Given your scenario, where the UC managed storage is accessible only through Azure Private Endpoints, the PERMISSION_DENIED error returned during MLflow/Zerobus trace-location validation is consistent with this documented limitation. The fact that:

NCC connectivity has been configured and validated,
Serverless SQL Warehouses can access the storage,
Unity Catalog itself is functioning correctly,

does not necessarily mean the MLflow trace ingestion path supports Private Link-protected storage. MLflow trace ingestion uses a separate service path with its own connectivity requirements. [docs.databricks.com], [learn.microsoft.com]

Therefore, the answer to your question is yes: MLflow 3 Unity Catalog trace ingestion currently does not support trace storage locations backed exclusively by Azure Private Link / Private Endpoint protected storage. The doc alternatives today are to:

use a UC trace storage location that is not protected by Private Link, or
continue storing traces in the MLflow experiment until Private Link support becomes available. [docs.databricks.com]

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.