Assistance Required – Unable to Access Azure File Storage in the Azure VM from different Azure network

Question

We are using a Windows Server 2019 Datacenter Azure VM, and one of our clients has shared Azure File Storage credentials with us. While all credentials are working correctly, we are unable to access the file storage.

We have already ensured the following:

• Outbound port 445 is open.
• Our IP address is whitelisted on the client’s side.

Despite these configurations, we are still encountering an "Access Denied" error when attempting to map the Azure file share.

Could you please advise on what might be causing this issue? Additionally, let us know if there are any other settings we need to configure on our end.

Looking forward to your guidance.

Answer 1

Hello，

Below are several common causes and troubleshooting steps :

1. Verify the Whitelisted IP(s) Are Correct

 • In many cases the issue is that the IP address seen by the storage account isn’t the one you expect. Azure VMs (especially if they’re behind a NAT or load balancer) can have a different outbound public IP address than the one you use to log in. Double‐check with the client that the exact public IP (or address range) of your VM’s outbound traffic is on their allowed list.

 • If your VM sits in a virtual network that uses a NAT gateway or has an SNAT configuration, confirm that the NAT’s public IP is whitelisted rather than the VM’s private or assigned IP.

2. Confirm the Authentication Method

 • Azure Files supports two different authentication methods: using storage account keys (or shared access signatures) and Azure AD (either Domain Services or AD DS–integrated).

 • Verify you’re using the correct credential type. If your client provided you with storage account keys (or a SAS), ensure that you are not inadvertently attempting an AD authentication.

 • In some cases, if the storage account’s “Allow shared key access” setting is disabled, you’ll only be able to connect using Azure AD credentials.

3. Check Encryption and SMB Protocol Requirements

 • Modern Azure File shares require usage of SMB 3.0 (which includes encryption by default). In a few cases, if there is a mismatch in SMB version or if encryption is enforced on the storage account (for secure transfer), a client using an older version may face an “Access Denied” error.

 • Confirm that your Windows Server 2019 VM is using SMB 3.0 when mapping.

4. Review Storage Account Firewall and Networking Settings

 • Besides IP whitelisting, the storage account itself could be set to accept traffic only from certain virtual networks. Ask your client if the storage account’s firewall rules are configured solely for traffic from specific virtual networks or regions.

 • If that’s the case, you might need to set up a service endpoint (or private endpoint) or ask the client to include your VM’s virtual network/subnet rather than just the public IP.

5. Inspect Local Firewall and NSG Settings on Your VM

 • Although you’ve ensured outbound port 445 is available, double-check that there isn’t a local Windows Firewall or a network security group (NSG) rule blocking responses or related traffic on the VM.

 • Confirm that any antivirus or endpoint security software isn’t interfering with SMB connections.

6. Map the Share Using the Correct Syntax and Credentials

 • Ensure that you are using the correct UNC path (\storageaccountname.file.core.windows.net\sharename) and that your command or mapping script is providing the proper username (often in the form of “Azure[storageaccountname]”) along with the shared access key if using storage account key authentication.

 • Typos or formatting issues in the path/credentials can also produce “Access Denied” errors.

By going through these steps, you can narrow down whether the problem is due to networking (such as incorrect IP whitelisting), authentication mismatches between storage key versus AD, or configuration settings inside the client’s storage account. Often the culprit is that the actual outbound IP address for your Azure VM (especially if using NAT or a load-balancer) isn’t the one you expect and isn’t the one that’s been granted access on the client’s side.

If after verifying these points the issue still persists, it might be valuable to enable SMB logging on the Windows Server, capture network trace (using tools like Wireshark), and review the Azure storage account’s diagnostic logs (if available) to see if they reveal any additional details about the denied requests.

---

If the Answer is helpful, please click "Accept Answer" and upvote it.