Windows container UNC access: the name first, the identity second

A Windows container that needs a share on the other side of your tunnel fails in two independent ways, and the host's Explorer proves neither of them. The container has its own network endpoint and its own process identity. A name that resolves on the desktop and a session the file server accepts there describe the desktop, not the workload.

The host's Explorer is not evidence

Opening the share on the host uses the host's DNS client, the host's routing table and the host's logged-on account. A container process inherits none of those implicitly, even when the container runs on the same machine and the VPN client runs there too. The first boundary is the network path: can the container resolve the name, and can it open a TCP session to the SMB port. The second is identity: does the file server accept what the container presents, with the permissions the workload needs.

Treating them as one problem produces the familiar loop of widening firewall rules to fix what is actually an access-denied answer from the share.

Follow the container's own request

Windows container networking is managed by the Host Networking Service, which creates endpoints with their own network namespace. The mode you selected decides whether the endpoint is translated, bridged, or attached to a network shared with the host. That decision changes two things at once: what the container can resolve, and what source address the file server sees.

Confirm what the container itself observes before changing anything. A name that resolves outside may fail inside, because the container's DNS configuration is not the host's, and a translated endpoint may present a source that the file server's rules do not expect.

docker exec -it app powershell -Command "Resolve-DnsName files.corp.example"
docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445"
docker exec -it app powershell -Command "Get-NetIPConfiguration"

If resolution fails, fix DNS in the network configuration rather than substituting an address. Replacing the name with an IP can change authentication and server identity behaviour, which turns one problem into two. The VPN client's own policy is the next thing to check, because it may treat host processes and container-originated traffic differently.

Identity is a separate decision

A drive letter mapped by an interactive user is not an application interface. It exists in one logon session, and a container process is not part of it. Use the UNC path and give the workload an identity that the deployment model supports. Where the domain supports it, a group Managed Service Account provides a managed identity through a credential specification.

Microsoft's container gMSA guide describes that credential-spec arrangement and its prerequisites, which include domain membership and a host able to retrieve the credential. The account, the retrieval, the process identity inside the container and the share permissions all have to line up. A VPN login is not that identity, and baking a password into an image to reproduce the host user's session creates a standing exposure.

Keep the failing stage visible

A resolution failure, a connection refusal and an access denial need different evidence. They are a DNS question, a routing or filtering question, and an authentication or permission question respectively. Read the response the container received rather than the application's generic error.

Test with the workload's own identity and test a denial as well.

Plan for the reconnect

VPN paths drop. When the tunnel returns, an endpoint may come back with a different translated address, and an existing SMB session may be dead without the application noticing. Handle that in the application: re-establish the path and the identity, retry the operation, and reconcile a file operation with an unknown result instead of assuming nothing happened.

Record the network mode, the DNS source and the identity arrangement in the deployment notes. Those three facts are what the next failure will be about.