@Rocky StarRocks 4.1 shared-data, writing to Databricks Unity Catalog managed Iceberg table on ADLS Gen2. Credential vending returns SAS Token successfully, but write fails with "Failed to create file". Is writing to UC-managed Iceberg tables on ADLS supported in 4.1? If so, why fail?

In StarRocks 4.1, writing to Databricks Unity Catalog (UC) managed Iceberg tables on ADLS Gen2 is supported via the Iceberg REST Catalog interface. StarRocks 4.1 introduced significant enhancements for "vended credentials" in REST catalogs, including better caching and refreshing of tokens to support long-running write operations. The "Failed to create file" error, despite a successful credential vending, typically points to a mismatch between the vended SAS token's scope and the write operation requirements, or a protocol configuration issue. Why the write might fail: 1. SAS Token Permissions: Databricks Unity Catalog generates the SAS token. If the UC "External Location" or the underlying Storage Credential in Databricks does not have Write or Delete permissions (specifically

Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write

), the token will allow the catalog to "vend" but the StarRocks BE (Backend) will fail when actually attempting to create the Parquet files. * Action: Ensure the Service Principal used by Unity Catalog has the "Storage Blob Data Contributor" role on the ADLS Gen2 container. 2. SAS Token Type Mismatch: StarRocks requires a SAS token that is valid for the

abfss

(Azure Blob File System) protocol. Sometimes, tokens vended as "Blob SAS" tokens lack the necessary permissions for the "Filesystem" (DFS) endpoint used for high-performance ADLS Gen2 writes. 3. Protocol Configuration: Ensure your Iceberg Catalog in StarRocks is explicitly configured to use vended credentials and the correct Azure properties. Check if these properties are set in your

CREATE EXTERNAL CATALOG

statement: *

"iceberg.catalog.vended-credentials-enabled" = "true"

(This is the default in 4.1, but should be verified). *

"azure.adls2.storage_account" = "<your_account>"

(Even with vended credentials, StarRocks often needs the account name to resolve the endpoint correctly). 4. Clock Skew: Azure SAS tokens are very sensitive to time. If your StarRocks BE nodes have a clock skew relative to Azure/Databricks, the vended token might be considered "not yet valid" or "expired" immediately upon receipt. * Action: Sync all FE and BE nodes using NTP. 5. Concurrent Write Limitations (Preview Status): Writing to Unity Catalog managed Iceberg tables via the REST API is a relatively new feature on the Databricks side (often labeled as Public Preview). Ensure that your Databricks workspace has "Managed Iceberg" writes enabled and that the table is not a "Uniform" table (which has specific read-only constraints for certain external writers). Recommended Debugging Steps: * Check BE Logs: Examine the

<http://be.INFO|be.INFO>

or

be.WARNING

logs on the nodes performing the write. Look for a more detailed Azure error code (e.g.,

403 AuthorizationFailure

or

403 AccountIsDisabled

). * Verify Storage Path: Ensure the

warehouse

location in the catalog uses the

abfss://

prefix. StarRocks uses this to determine the correct driver for ADLS Gen2. * Test with Static Key: To isolate whether the issue is with Credential Vending or General Connectivity, try creating a temporary test catalog using a static

azure.adls2.shared_key

. If that works, the issue is strictly with the token provided by UC. If the issue persists, verify that your UC version supports managed Iceberg writes from third-party engines, as Databricks initially only supported "External" (Foreign) Iceberg writes. References • integrations/authenticate_to_azure_storage.md