Worktree fix lxc docker nfs mounts

Conversation 0 Commits 2 Files Changed 4

+144 -26

2 Commits

Author	SHA1	Message	Date
beatzaplenty	75d09d57e3	Fix --allow-duplicate-host creating real duplicates in create-proxmox-resource.sh Check NixOS configurations / eval-hosts (pull_request) Failing after 11m24s Details --allow-duplicate-host previously just skipped the existing-resource check entirely, so re-running e.g. --type lxc --host docker while an lxc-docker container already existed created a second container sharing the same hostname/identity instead of replacing it -- both then fight over DNS/DHCP for that hostname, and it's easy to end up testing the stale one without realizing. Now splits matches into "exact" (same --type as the one being created, e.g. another lxc-docker) and "cross-type" (a different platform sharing this host identity, e.g. a proxmox-docker VM alongside an lxc-docker container -- a deliberate, valid coexistence this script has never managed and still won't). Only an exact match is destroyed and replaced, after typing the hostname back to confirm; a cross-type match is always left untouched. Without --allow-duplicate-host, both cases still refuse to run exactly as before. Verified live against pve.sweet.home: correctly split VMID 103 (a stopped proxmox-docker VM, cross-type -- left untouched) from VMID 105 (the running lxc-docker container, exact-type -- flagged for destroy+replace), and confirmed the destroy prompt safely aborts on a non-matching confirmation, leaving both resources untouched.	2026-07-20 13:22:08 +00:00
beatzaplenty	6847a7a6f4	Fix NFS shares never mounting on lxc-docker Two compounding bugs, confirmed live on the running lxc-docker container (vmid 102 on pve.sweet.home): 1. x-systemd.automount never works inside any Linux container -- systemd logs "Starting of <unit>.automount unsupported" for every share and never mounts them. modules/docker/mount-data.nix and modules/raspi/mount-data.nix now key off config.boot.isContainer (set true by nixpkgs' proxmox-lxc.nix) to mount eagerly with `nofail` there instead, while VM-based docker targets keep automount unchanged. 2. The container's Proxmox `features` never included `mount=nfs`, so AppArmor blanket-denies the nfs/rpc_pipefs mount syscalls NFS needs ("permission denied"). scripts/env.sh's PROXMOX_DEFAULT_LXC_FEATURES now includes mount=nfs;nfs4 for future lxc-* containers -- the semicolon required quoting the --features value in create-proxmox-resource.sh's remote pct-create command, since it's sent as a raw string for the remote shell to parse and an unquoted `;` would be read as a command separator. The already-running container needs a matching `pct set --features` plus a restart to pick this up -- that's an operator step outside this repo.	2026-07-20 12:56:42 +00:00

Author

SHA1

Message

Date

beatzaplenty

75d09d57e3

Fix --allow-duplicate-host creating real duplicates in create-proxmox-resource.sh

Check NixOS configurations / eval-hosts (pull_request) Failing after 11m24s

Details

--allow-duplicate-host previously just skipped the existing-resource
check entirely, so re-running e.g. --type lxc --host docker while an
lxc-docker container already existed created a second container
sharing the same hostname/identity instead of replacing it -- both
then fight over DNS/DHCP for that hostname, and it's easy to end up
testing the stale one without realizing.

Now splits matches into "exact" (same --type as the one being
created, e.g. another lxc-docker) and "cross-type" (a different
platform sharing this host identity, e.g. a proxmox-docker VM
alongside an lxc-docker container -- a deliberate, valid coexistence
this script has never managed and still won't). Only an exact match is
destroyed and replaced, after typing the hostname back to confirm; a
cross-type match is always left untouched. Without
--allow-duplicate-host, both cases still refuse to run exactly as
before.

Verified live against pve.sweet.home: correctly split VMID 103 (a
stopped proxmox-docker VM, cross-type -- left untouched) from VMID 105
(the running lxc-docker container, exact-type -- flagged for
destroy+replace), and confirmed the destroy prompt safely aborts on a
non-matching confirmation, leaving both resources untouched.

2026-07-20 13:22:08 +00:00

beatzaplenty

6847a7a6f4

Fix NFS shares never mounting on lxc-docker

Two compounding bugs, confirmed live on the running lxc-docker
container (vmid 102 on pve.sweet.home):

1. x-systemd.automount never works inside any Linux container --
   systemd logs "Starting of <unit>.automount unsupported" for every
   share and never mounts them. modules/docker/mount-data.nix and
   modules/raspi/mount-data.nix now key off config.boot.isContainer
   (set true by nixpkgs' proxmox-lxc.nix) to mount eagerly with
   `nofail` there instead, while VM-based docker targets keep automount
   unchanged.

2. The container's Proxmox `features` never included `mount=nfs`, so
   AppArmor blanket-denies the nfs/rpc_pipefs mount syscalls NFS
   needs ("permission denied"). scripts/env.sh's
   PROXMOX_DEFAULT_LXC_FEATURES now includes mount=nfs;nfs4 for future
   lxc-* containers -- the semicolon required quoting the --features
   value in create-proxmox-resource.sh's remote pct-create command,
   since it's sent as a raw string for the remote shell to parse and an
   unquoted `;` would be read as a command separator.

The already-running container needs a matching `pct set --features`
plus a restart to pick this up -- that's an operator step outside this
repo.

2026-07-20 12:56:42 +00:00

Worktree fix lxc docker nfs mounts #14