Context
A private endpoint for Blob Storage does not automatically provide private SMB access to Azure Files. Storage services have separate endpoints, and SMB adds a transport and identity contract beyond ordinary HTTPS access. A successful portal view therefore cannot establish whether a user's workstation can mount a share.
Prerequisites are the storage account name, share name, client network and exact mount error. Obtain read access to the private endpoint configuration and DNS path. Identify the client's intended VPN or ExpressRoute route and use a host on that same path for diagnosis.
1. Check the file service endpoint
Inspect the private endpoint's target subresource and approval state. It must serve the file service for this workflow. Record its private IP and connected network. Check whether the client is expected to reach it directly or through a hybrid connection.
Use the ordinary storage hostname, such as exampleaccount.file.core.windows.net, in the mount design. A private IP substituted directly into a mount command may bypass the name expected by identity authentication. Do not treat an IP-based test as a validated long-term SMB configuration.
2. Verify DNS from the actual client
Run Resolve-DnsName exampleaccount.file.core.windows.net on an authorized Windows client, replacing the example name. Trace the response chain to its private address. Compare the answer with one from a known working client, including which DNS server was used.
For hybrid access, inspect the relevant conditional forwarding and the private zone's network visibility. The file service uses its own private DNS namespace. A working Blob private zone does not prove that the file record exists. Capture the current answer before clearing caches so useful evidence is retained.
3. Test transport before authorization
Run Test-NetConnection exampleaccount.file.core.windows.net -Port 445 as a scoped connectivity check. A timeout requires route, firewall or transport investigation before ACL changes. SMB uses TCP 445; HTTPS success on port 443 does not validate this path. Include both directions of the hybrid network in the review.
When transport works, mount using the approved identity mechanism and test the required operation. If the mount reaches the service but returns Access denied, investigate identity, share roles and Windows ACLs separately. Avoid switching permanently to an account key just because it changes the error.
Diagnostic checkpoints
| Result | Suspected boundary | Next check |
|---|---|---|
| Host resolves publicly | File DNS path | Zone and forwarding |
| Private address, TCP timeout | Routing or filtering | TCP 445 path |
| TCP succeeds, login denied | Authentication | Identity prerequisites |
| Share opens, folder denied | Authorization | Share role and ACL |
Illustrative scenario
A hypothetical remote office can browse storage over HTTPS but cannot mount its finance share. The account has a Blob endpoint, while its file service still resolves publicly and outbound SMB is blocked. The correction requires a reviewed file endpoint and hybrid DNS/network path. This example is illustrative and claims no real migration result.
Verification and mount SOP
Validate a fresh mount from the intended client network, using the canonical hostname and ordinary user credentials. Read a known file and perform an approved write test if the user requires writing. Verify that the DNS answer remains private after reconnecting the VPN.
Maintain endpoint subresources, DNS ownership and permitted SMB paths in the SOP. Monitor mount failures separately from file authorization failures. Retest representative remote networks after VPN, DNS or firewall changes; a successful mount from an Azure VM cannot stand in for every office access path.
Explore Clouvenix managed infrastructure for implementation and operational handover.