Local Samba Share Vanished After OpenVPN Pushed DNS

Samba loses local shares the moment OpenVPN connects, and the tunnel is almost never the cause. The mount is fine, the NAS is up, and the resolver the tunnel installed is answering questions about a name it has never seen. Samba asks that resolver early in its lookup order, believes the answer, and connects to an address where nothing is listening. Fixing the share means fixing the answer rather than the mount.

Five checks, in the order that eliminates the most possibilities per step.

Who answers for the short name

Ask the operating system, not the file manager. resolvectl status prints the DNS servers attached to each link and marks which link is the default route, and a query for the short name reports the server that replied. Run it once for the NAS name and once for a name you know exists in the office domain. If the two answers come from different servers, you have found the split.

Check whether the reply was a negative answer or an address. A negative answer means Samba should have moved on to another mechanism, and the failure is elsewhere. An address means Samba connected somewhere real and got nothing back.

Why Samba believes a wrong answer

Samba resolves names through a fixed sequence set by name resolve order. On most distributions the default includes host, which means DNS, and it runs before the LAN-only mechanisms such as NetBIOS broadcast. A tunnel that pushes a resolver therefore gets first refusal on every share name, including single-label names that were never meant to leave the building.

Normally an unknown name returns a negative response and the next mechanism gets a turn. Some resolvers, especially consumer ISP and public ones, answer unknown names with a search page or an advertising address instead. That reply looks like success to the resolver library, so Samba stops looking and dials an address that has nothing to do with your network.

The result is a share that vanishes without an error dialog. Nothing in that sequence is a VPN routing failure, which is why pinging the NAS still works while browsing to it does not.

Two repairs with different scopes

The narrow repair keeps the pushed resolver and changes what Samba is allowed to ask it. Add two lines to the Samba configuration the daemon actually reads, then restart the service:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

With no host in that list, DNS is out of the path for share lookups, and single-label names stay on the local segment. Office names still resolve normally for every other program, because this changes only Samba. The cost is that Samba can no longer use DNS at all, so a share addressed by a fully qualified office name becomes a problem.

The broad repair removes the cause: stop pushing a resolver that answers names it does not own, or push a split-DNS policy so that only office suffixes reach the office resolver. That is the better long-term answer on a managed network because it protects the browser and the package manager too, but it needs administrative access to the server side and a client that obeys the pushed settings.

Pick one deliberately. A resolver change alters name resolution for every application at once, which is a change record, not a support-call edit.

The suffix can explain everything

If the client also pushes a search suffix, a short local name is rewritten into the office domain before it is queried. Then the resolver is not lying at all: it was asked a fair question about an office name and gave a correct answer. Read the queried name in the resolver output to tell this apart from the advertising-address case, because the two failures look identical in the file manager.

The fix here is either to use the fully qualified local name or to add a split-DNS rule that owns the local suffix. Neither requires touching Samba.

Prove it after a reconnect

Test three names in one session: the local share by short name, an office host by name, and an ordinary website. If the first works and the second breaks, the repair moved the fault instead of removing it. If the third breaks, the resolver change went further than intended and every lookup is now suspect.

Then disconnect and reconnect the tunnel and repeat all three. Pushed options are reapplied on every connect, so a fix that only existed at runtime can disappear without a configuration file changing. Record the resolver that owns each suffix and the lookup order in force, and note the date, because the next client update is the obvious suspect when this returns.

If the share still fails after all five checks, capture the exact query and the exact reply before changing anything else. That pair of lines distinguishes a resolver fault from a name that genuinely does not exist, and it is the fastest handover note you can write.