Fix NFS mount device strings on lxc-docker: use FQDN, not search domain #25

Merged

beatzaplenty merged 1 commits from worktree-fix-container-dns-search-domain into main

2026-07-21 04:26:39 +00:00

Author	SHA1	Message	Date
beatzaplentyandClaude Sonnet 5	42da626397	Fix NFS mount device strings on lxc-docker: use FQDN, not search domain Check NixOS configurations / eval-hosts (pull_request) Successful in 17m29s Details The previous commit's networking.search fix was wrong. Confirmed live on lxc-docker (vmid 105) after redeploying with it: `resolvectl query server.sweet.home` started failing again, even though `resolvectl query --interface=eth0 server.sweet.home` still resolved correctly to the right IP via the LAN's real DNS server. The debug log showed why -- adding a global search domain via networking.search gave systemd-resolved a domain-matched but server-less "global" scope, which it now prioritizes over eth0's correctly-configured scope for every "*.sweet.home" query, silently sending them to public fallback DNS (1.1.1.1 et al) instead, which of course returns NXDOMAIN for an internal-only name. Bare single-label names (e.g. "server") were never going to work either way -- systemd-resolved only ever tries LLMNR for those, never DNS search-suffixing, regardless of configuration. Reverts the networking.search addition and instead has modules/docker/mount-data.nix build each NFS device string from "${vars.nfsServerHost}.${vars.homeDomain}" (a plain FQDN, no dependency on search-domain behavior at all) -- the same pattern modules/raspi/mount-data.nix already uses for the Raspberry Pi's share and for the identical reason. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T48qgH3VTvs8wvwj44FEbE	2026-07-21 01:19:42 +00:00

Author

SHA1

Message

Date

beatzaplentyandClaude Sonnet 5

42da626397

Fix NFS mount device strings on lxc-docker: use FQDN, not search domain

Check NixOS configurations / eval-hosts (pull_request) Successful in 17m29s

Details

The previous commit's networking.search fix was wrong. Confirmed live
on lxc-docker (vmid 105) after redeploying with it: `resolvectl query
server.sweet.home` started failing again, even though
`resolvectl query --interface=eth0 server.sweet.home` still resolved
correctly to the right IP via the LAN's real DNS server. The debug log
showed why -- adding a *global* search domain via networking.search
gave systemd-resolved a domain-matched but server-less "global" scope,
which it now prioritizes over eth0's correctly-configured scope for
every "*.sweet.home" query, silently sending them to public fallback
DNS (1.1.1.1 et al) instead, which of course returns NXDOMAIN for an
internal-only name. Bare single-label names (e.g. "server") were never
going to work either way -- systemd-resolved only ever tries LLMNR for
those, never DNS search-suffixing, regardless of configuration.

Reverts the networking.search addition and instead has
modules/docker/mount-data.nix build each NFS device string from
"${vars.nfsServerHost}.${vars.homeDomain}" (a plain FQDN, no dependency
on search-domain behavior at all) -- the same pattern
modules/raspi/mount-data.nix already uses for the Raspberry Pi's share
and for the identical reason.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T48qgH3VTvs8wvwj44FEbE

2026-07-21 01:19:42 +00:00