Azure Files BYOS mount never mounts on Windows Web App (P0v4, zone-redundant) — C:\mounts empty, state "NotValidated", connectivity to private endpoint verified

Iu Donadeu Renau 45 Reputation points
2026-07-10T10:57:31.2666667+00:00

I have a Windows Web App that fails to mount an Azure Files share via Path mappings (BYOS). The mount never appears: C:\mounts is empty on both instances, verified from a diagnostic .aspx page running inside w3wp (not Kudu).

Environment:

  • Web App: Windows, .NET Framework, App Service Plan P0v4, zone redundancy enabled (2 instances), region Spain Central
  • Storage account: public network access disabled, private endpoint only (sub-resource "file", connection Approved, same VNet)
  • Mount config: Azure Files, SMB, mount path /mounts/appsdata
  • az webapp config storage-account list shows state: "NotValidated"

What I've verified (all OK):

  1. VNet integration enabled on the app, dedicated delegated subnet, same VNet as the private endpoint. "Outbound internet traffic" (Route All / vnetRouteAllEnabled) is ON.
  2. DNS: nameresolver from Kudu resolves the storage FQDN (xxx.file.core.windows.net) to the correct private endpoint IP (10.1.34.x), via our custom DNS servers in the VNet. The PE NIC IP matches.
  3. Connectivity: tcpping to storage FQDN :443 from Kudu succeeds (<1 ms). Port 445 cannot be tested from Kudu due to sandbox restrictions (expected).
  4. Storage account: "Allow storage account key access" = Enabled. File share SMB security profile = Maximum compatibility (SMB 3.1.1, NTLM v2 enabled). Share is SMB (not NFS).
  5. Mount recreated multiple times: Basic mode and Advanced mode (key1 pasted manually). Full Stop/Start of the app after each change. No change.
  6. No NSG on the subnets involved.
  7. "Diagnose and solve problems" detectors report no outbound TCP connection issues. (The flagged "requests rejected due to Access Restrictions" refers to inbound traffic to the app, unrelated.)

Question:

  • Where can I see the platform's internal mount failure logs / the actual error behind "NotValidated"?
  • Are there known limitations for BYOS Azure Files mounts on P0v4 or zone-redundant plans with storage behind a private endpoint?
  • Is there any additional requirement (app setting, e.g. WEBSITE_DNS_SERVER) for the platform mount process to resolve/reach a private endpoint when using custom DNS in the VNet?

Any pointer to get the real mount error would be appreciated.

Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

Answer accepted by question author
Venkatesan S 10,830 Reputation points Microsoft External Staff Moderator
2026-07-10T12:31:21.7766667+00:00

Hi @Iu Donadeu Renau ,

Thank you for providing the detailed troubleshooting information. Based on the information shared, your configuration appears to be aligned with the documented requirements for Azure Files BYOS mounts in App Service, including VNet Integration, Route All enabled, Private Endpoint configuration, DNS resolution to the private endpoint, SMB-based Azure Files share, and valid storage account key access.

Regarding the "NotValidated" status

The NotValidated state generally indicates that the App Service platform was unable to complete the storage mount validation process before attaching the Azure Files share to the worker instance. Unfortunately, the detailed validation logs used by the platform are not exposed to customers through the Azure portal, Kudu, or standard App Service diagnostics. In most cases, the underlying reason must be reviewed through internal App Service platform logs by Microsoft Support.

Because the mount directory is not being created under C:\mounts on either worker instance, the key question is determining whether the validation is failing due to:

  • DNS resolution of the storage endpoint
  • SMB connectivity over TCP 445
  • Azure Files authentication using the provided storage key

Known limitations

At this time, we are not aware of any documented limitation that prevents Azure Files BYOS mounts from working on:

  • Windows App Services
  • Premium v4 App Service plans (including P0v4)
  • Zone-redundant App Service plans
  • Storage accounts secured through Private Endpoints, when used together with VNet Integration

Microsoft documentation specifically states that Azure Storage mounts for App Service support secured storage access scenarios, including Private Endpoints and Virtual Network Integration.

DNS and Private Endpoint considerations

Since your storage account is accessible only through a Private Endpoint, DNS resolution becomes a critical dependency for the mount process. Although your nameresolver tests show that the storage account FQDN resolves to the correct private IP address, it is important to ensure that:

  • The storage account resolves through the complete privatelink.file.core.windows.net DNS chain.
  • The VNet-integrated application is using DNS servers that can resolve the Private Endpoint records correctly.
  • Any custom DNS infrastructure is forwarding Azure private DNS zones appropriately.

When custom DNS servers are being used, the WEBSITE_DNS_SERVER application setting can be relevant and may help ensure that the application environment uses the intended DNS resolver path. However, there is no indication from the documentation that this setting is universally required for BYOS mounts.

SMB connectivity

One item that remains difficult to validate from the App Service sandbox is SMB communication over TCP** **445. While your successful DNS resolution and TCP 443 connectivity tests are good indicators, they do not confirm that the platform's mount process can successfully establish an SMB session to Azure Files. Microsoft documentation notes that Azure Files mounts require the necessary SMB ports to be reachable when using VNet Integration.

Next recommended step

Given the extensive troubleshooting already completed, the most effective next step would be to continue the investigation through Azure App Service Support so that the platform-side BYOS validation logs can be reviewed for the worker instances and timestamps you provided. This will allow us to determine whether the mount validation is failing because of DNS resolution, SMB connectivity, or storage authentication.

Official Documentation

I hope this helps clarify the current findings and the next steps for isolating the root cause.

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to 210246-screenshot-2021-12-10-121802.pngand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Alex Burlachenko 25,285 Reputation points MVP Volunteer Moderator
    2026-07-10T12:25:15.1766667+00:00

    hi Iu Donadeu Renau & thx for sharing urs issue here at Q&A portal,

    NotValidated usually means the App Service platform mount validation failed before the share was attached. The fact that DNS resolves correctly and TCP 443 works is useful, but SMB needs TCP 445. A successful 443 test doesn’t prove the mount path is reachable. There isn’t a customer-visible log that shows the full internal BYOS mount failure in many cases. Some details may appear in App Service diagnostics or platform logs, but the real mount error often needs Microsoft support to pull from the worker/platform side. I’m not aware of a general restriction for Azure Files BYOS on P0v4 or zone-redundant Windows plans. The more likely issue is that the platform mount process can’t resolve the private endpoint through the same DNS path as the app worker, or it can’t reach SMB 445 from one or both instances.

    WEBSITE_DNS_SERVER can matter when custom DNS is used. Make sure the app is actually configured to use the VNet DNS servers and that those servers can resolve the privatelink.file.core.windows.net chain correctly. Also verify there’s no firewall or NVA blocking 445 on the return path. At this point, the setup looks mostly correct, so I’d open an App Service support case and ask them to check the BYOS mount validation logs for both workers. Include the app name, storage account, mount name, region, timestamps, and the NotValidated output. The useful question for support is whether the mount process is failing on DNS, SMB connectivity, or storage authentication.

    rgds,

    Alex

    &

    If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

    and at my blog https://ctrlaltdel.blog/

     

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.