Some troubleshooting clue when mounting storage in App Service

Posted by

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

 

In some special cases, we may notice that there is a network path error when mounting an Azure storage in an App Service.

theringe_0-1668495236317.png

 

Error Message: The network path was not found

 

According to the message itself, it is more likely to be a network problem, so we can find some clues regarding such an area.

 

Clue 1: Check domain resolving behavior and network connectivity

 

Just like most of the network related cases, we firstly want to verify the connectivity between resources, in this case, we could use kudu in app service and try to reach out the storage account.

 

 

nslookup <your_storage>.file.core.windows.net nameresolver <your_storage>.file.core.windows.net

 

 

There 2 commands use to figure out the domain resolving behavior, which we could get the IP address from that storage. We might get public/private IP address based on the different network scenario.

 

 

tcpping <your_storage>.file.core.windows.net:80 tcpping <your_storage>.file.core.windows.net:445

 

 

There are 2 commands used to figure out the network connectivity from app service to storage, azure files use port 80 and 445.

theringe_1-1668494928608.png

 

 

 

Clue 2: Check Private endpoint and VNET integration

 

For secure network, applying a Private endpoint on the Storage Account is necessary, apps with VNET integration use private endpoint to secretly access the storage under private network.

 

According to this document, there are several things we have to be noticed that when applying Private endpoint on the Storage Account.

theringe_2-1668494928609.png

 

 

Regarding domain resolving behavior, we would get the private IP address from storage under this network scenario.

theringe_3-1668494928612.png

 

 

 

Clue 3: Try to figure out the whole network architecture.

 

Here is an example:

theringe_4-1668494928614.png

 

 

As you can see, applying a private endpoint on the storage account could only effect on the VNET itself, not the whole peering networks, that is, we must create a virtual network link from Private DNS Zone to the VNET which containing the invoker (i.e., the App).

 

The point is, there are different limitations under diverse scenarios, try to figure out the network architecture is necessary.

 

 

Clue 4: Special Case

 

It is a very special case, if the Storage account both enables Private endpoint and public access. It might eventually block the connections via public network even if the network connectivity between the resources is fine.

 

This is because Azure Engineers recently made a change on our scale units to lock down our infrastructure storage accounts with infrastructure VNET. This was done to enhance network level security on the service.

 

So, according to the statement, when using Private endpoint, it is recommended to reach out the storage under private network for secure reason.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.