An Azure service that provides an enterprise-wide hyper-scale repository for big data analytic workloads and is integrated with Azure Blob Storage.
The failure matches SnowflakeFailToAccess: Snowflake can read the source metadata, but the Snowflake COPY command cannot access the target storage location. The documented cause is missing access permission on the source or sink when Snowflake executes the copy.
For Snowflake to write from Azure Data Factory to Azure Data Lake Storage, use one of these supported patterns:
- Direct copy
- Direct copy supports Azure Blob Storage linked service with shared access signature (SAS) authentication.
- For Azure Data Lake Storage Gen2, create an Azure Blob Storage linked service with SAS authentication against the ADLS Gen2 account to avoid staged copy.
- When generating the SAS token, make sure the allowed permissions and allowed IP addresses include Snowflake.
- Staged copy
- The staging Azure Blob Storage linked service must use SAS authentication.
- When generating the SAS token, make sure the allowed permissions and allowed IP addresses include Snowflake.
For the storage/network side, if ADLS Gen2 access is blocked by firewall rules, the documented checks are:
- In the storage account, verify whether Public network access is disabled.
- If it is disabled, use a managed virtual network integration runtime and create a private endpoint to access the storage.
- If the storage account allows selected virtual networks and IP addresses:
- Add the Azure Integration Runtime IP addresses or the self-hosted Integration Runtime IP address to the storage firewall.
- If Allow trusted Azure services is enabled on the storage firewall, copy activity must use managed identity authentication.
- If using service principal or managed identity authentication for ADLS Gen2:
- Grant at least Storage Blob Data Reader for source access.
- Grant at least Storage Blob Data Contributor for sink access.
Important limitation from the Snowflake connector behavior:
- For direct copy from Snowflake, the supported sink linked service is Azure Blob Storage with SAS authentication.
- If writing to ADLS Gen2 directly, the supported approach is to use an Azure Blob Storage linked service with SAS authentication against the ADLS Gen2 account.
A practical path for this scenario is:
- In ADF, keep Snowflake as source.
- Configure the sink as an Azure Blob Storage linked service using SAS against the ADLS Gen2 account.
- Regenerate the SAS token with the required permissions and with Snowflake allowed in the IP restrictions.
- In the ADLS Gen2 storage account firewall, either:
- allow the required Azure IR or self-hosted IR IPs, or
- if public access is disabled, move to managed VNet IR + private endpoint for storage access.
- If using identity-based access instead of SAS on the ADLS side, assign the required RBAC role for the sink: Storage Blob Data Contributor.
The screenshot error Failed to access remote file: access denied. Please check your credentials is consistent with storage permission or storage firewall/network restrictions rather than the Snowflake connection itself.
References: