---
title: "Troubleshoot storage account connectivity"
description: "Diagnose storage account connectivity and naming problems for Anyscale on Azure, including blob endpoint DNS resolution and globally unique naming."
---

# Troubleshoot storage account connectivity

Anyscale on Azure cluster pods read and write artifacts and dataset files through Azure Blob Storage. When pods can't reach the storage account, or when storage account creation fails outright, the cause is usually private endpoint configuration or the globally unique naming constraint.

For background on how Anyscale uses Azure storage, see [Access blob storage and ADLS](/clouds/azure/storage.md). For the network model, see [Networking](https://learn.microsoft.com/azure/anyscale-on-azure/networking).

## Pods can't resolve `<account>.blob.core.windows.net`

This symptom appears when the storage account is behind a private endpoint that your AKS cluster can't reach. Confirm the following:

-   The private DNS zone `privatelink.blob.core.windows.net` is **linked** to the VNet that hosts the AKS cluster. Without the link, the cluster's DNS resolver doesn't see the private endpoint records.
-   The private endpoint is in the **Approved** state. Pending endpoints don't route traffic.
-   The AKS cluster's outbound network configuration allows traffic to the subnet that hosts the private endpoint. Network security groups and Azure Firewall policies must allow the cluster's outbound traffic to reach the endpoint subnet.

Test resolution from inside a pod:

```bash
kubectl run -it --rm dns-test --image=busybox:1.36 --restart=Never -- nslookup <account>.blob.core.windows.net
```

A correctly configured private endpoint resolves to a private IP in the endpoint subnet. If the resolution returns a public IP or fails, work through the three checks above.

For the canonical private-endpoint setup procedure, see [Use private endpoints for Azure Storage](https://learn.microsoft.com/azure/storage/common/storage-private-endpoints).

## Creating the storage account fails with `StorageAccountAlreadyTaken`

Azure storage account names are globally unique across all Azure tenants. The name must be 3 to 24 characters, lowercase alphanumeric only. If the portal cloud creation flow rejects your storage account name with `StorageAccountAlreadyTaken`, pick a different name. The quickstart pre-populates a name based on your cloud name and a random suffix to avoid collisions. If you customize the name and hit this error, customize again with more entropy.

## Related Azure docs

-   [Networking](https://learn.microsoft.com/azure/anyscale-on-azure/networking) describes the required egress domains, private networking considerations, and TLS handling.
-   [Access blob storage and ADLS](/clouds/azure/storage.md) covers how Anyscale clusters authenticate to and read from your storage accounts.
-   [Use private endpoints for Azure Storage](https://learn.microsoft.com/azure/storage/common/storage-private-endpoints) is the canonical procedure for setting up private endpoints, DNS zones, and VNet links.
-   [Storage account name rules](https://learn.microsoft.com/azure/azure-resource-manager/management/resource-name-rules#microsoftstorage) lists the full naming constraints.

---

Previous: [Troubleshoot GPU pods stuck in Pending](/kb/azure/troubleshoot-gpu-pods-pending.md) | Next: [Troubleshoot Envoy Gateway on Anyscale on Azure](/kb/azure/troubleshoot-envoy-gateway.md)