Your CIFS Mount Fails Over VPN Because of nsswitch Order

The tunnel is up. The file server answers a ping by address. Then mount.cifs with the hostname sits there for a while and reports that the host is unreachable, and you start rebuilding a VPN profile that was never the problem. On Linux the name is resolved by glibc before any SMB packet exists, and the order in that resolver can end the lookup before DNS is ever asked. Here is the walk I do, starting from the command that failed rather than from the client.

Read the failure in the right place

Two tools use different paths to the same name, and comparing them costs one command. getent walks the configured name-service stack; host and dig query DNS directly and ignore that stack. If the direct query returns an address and getent returns nothing, the DNS server is reachable and your resolver configuration is what fails.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

The third command is the tiebreaker: it forces the DNS source and skips the rest of the stack. When that works and the plain getent does not, you have proved the order is the fault, not the tunnel and not the server.

The hosts line is a sequence that stops early

The glibc resolver reads /etc/nsswitch.conf and walks the hosts: entry from left to right. Many distributions ship a line where multicast lookup comes first with an early-return action attached. The action is not decoration: when mDNS answers "not found", [NOTFOUND=return] ends the whole lookup, so the corporate name is never sent to the resolver the VPN pushed. Nothing logs it, because no query was ever sent for the resolver to reject. That is why the mount appears to hang and then report an unreachable host.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

Move DNS ahead of the early-return action rather than deleting mDNS, and change it through configuration management. A hand edit survives until the next image build, and then the same ticket arrives from a different machine with no memory of the fix.

A resolver is not a search domain

Resolution also needs the name to be tried. An unqualified name like fileserver only becomes fileserver.corp.example when a search domain is attached to the interface carrying the query. A VPN that pushes a DNS server without a search list produces a very specific split: the fully qualified name resolves and every short name fails.

Test both forms before editing the profile, because the two failures point in different directions. On a systemd-resolved host the tunnel link owns its own servers and routing domains, so read the link rather than the global file.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

If the query is attributed to a link that does not carry the tunnel, the routing domain is missing even though the DNS address is present. That is a policy problem in the resolved configuration, not a routing problem in the tunnel.

Containers carry their own copy of the answer

A container built from a generic image usually ships a fixed resolv.conf. Resolver changes made on the host do not reach it, and neither does the search domain, so a build job that mounts a share over the tunnel fails while the same command works outside the container. Give the container its own DNS and search settings in the compose file or the run arguments, not just in the host profile.

Check inside the container before blaming the image. Two commands reproduce the whole diagnosis in a few seconds, and the second one proves which resolver actually answered.

Only then look at the share and the filter

Once the name resolves, the remaining failures are ordinary network ones. SMB needs TCP 445 to the server, and browsing a workgroup list depends on name services the tunnel probably does not forward. Map by hostname instead of waiting for a list to populate, and let the client tell you which stage it reached. A refused connection and a silent timeout are also worth separating, since the first usually means something answered and the second means nothing did.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

A resolved address with port 445 refused or timing out is a firewall or listener problem on the far side. An unresolved name is the resolver problem. And a mount that authenticates but returns permission errors is neither, so do not reopen the network question once the session is established.

Keep the conclusion as narrow as the evidence. When the address works and the name does not, the tunnel is doing its job and the fix belongs in the resolver order, the search domain, or the container's own configuration.