beatzaplenty/nixos
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add global DNS search domain to fix NFS mounts on lxc-docker #23

Merged
beatzaplenty merged 1 commits from worktree-fix-container-dns-search-domain into main 2026-07-21 00:11:23 +00:00
Conversation 1 Commits 1 Files Changed 1
+18
beatzaplenty commented 2026-07-21 00:08:43 +00:00
Owner
Copy Link
Copy Source

Cross-host references throughout this repo (vars.nfsServerHost, vars.nixCacheHost, vars.dockerHost) are bare short names, not FQDNs. Resolving them has always depended on whatever network stack happens to be in play picking up the DHCP-advertised domain as a search suffix -- NetworkManager does this by default, which is why it went unnoticed everywhere else, but LXC containers force-disable NetworkManager and get their systemd-networkd config written directly by Proxmox instead, which never sets one.

Confirmed live on lxc-docker (vmid 105) after todays earlier fix for the automount/mount=nfs bugs (6847a7a): systemd-resolved had no search domain for eth0, so server failed to resolve (Name or service not known) while server.sweet.home resolved fine via the same DNS server -- every NFS mount in modules/docker/mount-data.nix was still failing.

networking.search sets systemd-resolveds own Domains= globally rather than depending on the per-link DHCP path, so it isnt at the mercy of whichever component owns a given hosts interface file. Verified via nix eval that it produces Domains=sweet.home in /etc/systemd/resolved.conf for lxc-docker.

Test plan

  • nixpkgs-fmt --check clean
  • statix clean
  • Full nix eval of every host/package succeeds (this touches modules/common/*, which triggers the full fallback)
  • Operator: pull + nixos-rebuild switch on lxc-docker, confirm the 5 NFS mounts come up
Cross-host references throughout this repo (`vars.nfsServerHost`, `vars.nixCacheHost`, `vars.dockerHost`) are bare short names, not FQDNs. Resolving them has always depended on whatever network stack happens to be in play picking up the DHCP-advertised domain as a search suffix -- NetworkManager does this by default, which is why it went unnoticed everywhere else, but LXC containers force-disable NetworkManager and get their systemd-networkd config written directly by Proxmox instead, which never sets one. Confirmed live on `lxc-docker` (vmid 105) after todays earlier fix for the automount/`mount=nfs` bugs (6847a7a): systemd-resolved had no search domain for eth0, so `server` failed to resolve (`Name or service not known`) while `server.sweet.home` resolved fine via the same DNS server -- every NFS mount in `modules/docker/mount-data.nix` was still failing. `networking.search` sets systemd-resolveds own `Domains=` globally rather than depending on the per-link DHCP path, so it isnt at the mercy of whichever component owns a given hosts interface file. Verified via `nix eval` that it produces `Domains=sweet.home` in `/etc/systemd/resolved.conf` for `lxc-docker`. ## Test plan - [x] `nixpkgs-fmt --check` clean - [x] `statix` clean - [x] Full `nix eval` of every host/package succeeds (this touches `modules/common/*`, which triggers the full fallback) - [ ] Operator: pull + `nixos-rebuild switch` on `lxc-docker`, confirm the 5 NFS mounts come up
beatzaplenty added 1 commit 2026-07-21 00:08:58 +00:00
Add global DNS search domain to fix NFS mounts on lxc-docker
Check NixOS configurations / eval-hosts (pull_request) Failing after 40m2s
Details
e176ff723d 
Cross-host references throughout this repo (vars.nfsServerHost,
vars.nixCacheHost, vars.dockerHost) are bare short names, not FQDNs.
Resolving them has always depended on whatever network stack happens
to be in play picking up the DHCP-advertised domain as a search
suffix -- NetworkManager does this by default, which is why it went
unnoticed everywhere else, but LXC containers force-disable
NetworkManager and get their systemd-networkd config written directly
by Proxmox instead, which never sets one.

Confirmed live on lxc-docker (vmid 105) after today's earlier fix for
the automount/mount=nfs bugs: systemd-resolved had no search domain
for eth0, so "server" failed to resolve ("Name or service not known")
while "server.sweet.home" resolved fine via the same DNS server --
every NFS mount in modules/docker/mount-data.nix was still failing.

networking.search sets systemd-resolved's own Domains= globally
rather than depending on the per-link DHCP path, so it isn't at the
mercy of whichever component owns a given host's interface file.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T48qgH3VTvs8wvwj44FEbE
beatzaplenty merged commit d7aba8554d into main 2026-07-21 00:11:23 +00:00
beatzaplenty commented 2026-07-21 01:20:26 +00:00
Author
Owner
Copy Link
Copy Source

Correction: the original networking.search fix was wrong and has been reverted. Confirmed live on the redeployed lxc-docker (vmid 105): it caused systemd-resolved to prioritize a domain-matched-but-server-less global scope over eth0's correctly-configured one for every *.sweet.home query, silently routing them to public fallback DNS instead (which returns NXDOMAIN for an internal-only name). resolvectl query --interface=eth0 server.sweet.home resolved correctly throughout, proving the LAN DNS server was never the actual problem.

Replaced with a fix that side-steps DNS search-domain behavior entirely: modules/docker/mount-data.nix now builds each NFS device string from the FQDN (server.sweet.home) directly, matching the pattern modules/raspi/mount-data.nix already uses. Bare single-label names were never going to work anyway -- systemd-resolved only tries LLMNR for those, never DNS search-suffixing.

Also surfaced a separate, unrelated issue worth flagging: VMID 103 (the production docker VM) and VMID 105 (lxc-docker test container) are both live on the LAN and both declare networking.hostName = "docker", so they''re fighting over DNS/DHCP registration of docker.sweet.home. Left untouched per operator instruction -- flagging for awareness, not fixed in this PR.

Correction: the original `networking.search` fix was wrong and has been reverted. Confirmed live on the redeployed `lxc-docker` (vmid 105): it caused systemd-resolved to prioritize a domain-matched-but-server-less global scope over eth0's correctly-configured one for every `*.sweet.home` query, silently routing them to public fallback DNS instead (which returns NXDOMAIN for an internal-only name). `resolvectl query --interface=eth0 server.sweet.home` resolved correctly throughout, proving the LAN DNS server was never the actual problem. Replaced with a fix that side-steps DNS search-domain behavior entirely: `modules/docker/mount-data.nix` now builds each NFS device string from the FQDN (`server.sweet.home`) directly, matching the pattern `modules/raspi/mount-data.nix` already uses. Bare single-label names were never going to work anyway -- systemd-resolved only tries LLMNR for those, never DNS search-suffixing. Also surfaced a separate, unrelated issue worth flagging: VMID 103 (the production `docker` VM) and VMID 105 (`lxc-docker` test container) are both live on the LAN and both declare `networking.hostName = "docker"`, so they''re fighting over DNS/DHCP registration of `docker.sweet.home`. Left untouched per operator instruction -- flagging for awareness, not fixed in this PR.
This repo is archived. You cannot comment on pull requests.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
beatzaplenty
No Assignees
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: beatzaplenty/nixos#23