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

fix(lxc): auto-derive privileged from NFS fileSystems, not hostname list

Browse Source 
Replace the hardcoded hostname check (docker, pxe-boot) with a check
on config.fileSystems: any lxc-* host whose NixOS config declares an
NFS fileSystem entry is automatically made privileged. The script
already reads proxmoxLXC.privileged dynamically via
flake_target_lxc_privileged, so no logic change is needed there —
only the comment is updated to describe the new derivation.

Result: lxc-docker and lxc-pxe-boot (the two with NFS mounts) evaluate
as privileged=true; lxc-nix-cache, lxc-minimal, lxc-server,
lxc-tailscale-router, lxc-tor-relay evaluate as privileged=false.
Any future lxc-* host that declares an NFS mount gets the correct
privilege level for free without a separate manual edit.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
beatzaplenty
2026-07-27 05:27:56 +10:00
co-authored by Claude Sonnet 4.6
parent cf0d62696f
commit 48d6d6f7a2
2 changed files with 27 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files
modules/platforms/lxc.nix
+16 -19
View File
@@ -63,25 +63,22 @@ in
# back to decide `pct create`'s --unprivileged flag, so the two stay
# in sync).
#
# lxc-docker and lxc-pxe-boot are the exceptions: the kernel's NFS client
# doesn't set FS_USERNS_MOUNT, so mounting NFS from inside *any* non-init
# user namespace -- which is exactly what an unprivileged container's
# UID-mapped root runs in -- is rejected at the VFS layer with EPERM,
# no matter what Proxmox's own `mount=nfs;nfs4` container feature
# allows at the AppArmor layer (confirmed live: TCP to the NFS server
# succeeds, the server's export table matches the container's IP, and
# `mount.nfs: Operation not permitted` still fires immediately with no
# corresponding denial anywhere in the server's logs -- a kernel-level
# rejection, not a network or export-permission one). Keying off
# hostName rather than something build-type-specific because
# modules/build-types/{docker,pxe-boot}.nix are also composed for
# linode-docker/proxmox-docker/proxmox-pxe-boot, which don't import
# proxmox-lxc.nix at all -- setting this option there would break their
# eval with "option does not exist" regardless of any mkIf guard, since
# mkIf only makes a value conditional, not whether the option needs to
# exist somewhere.
privileged = config.networking.hostName == "docker"
|| config.networking.hostName == "pxe-boot";
# Any lxc-* host with an NFS fileSystem must be privileged: the kernel's
# NFS client doesn't set FS_USERNS_MOUNT, so mounting NFS from inside
# *any* non-init user namespace -- which is exactly what an unprivileged
# container's UID-mapped root runs in -- is rejected at the VFS layer
# with EPERM, no matter what Proxmox's own `mount=nfs;nfs4` container
# feature allows at the AppArmor layer (confirmed live: TCP to the NFS
# server succeeds, the server's export table matches the container's IP,
# and `mount.nfs: Operation not permitted` still fires immediately with
# no corresponding denial anywhere in the server's logs -- a kernel-level
# rejection, not a network or export-permission one). Deriving this from
# fileSystems rather than a per-host override keeps it self-consistent:
# any new lxc-* host that declares an NFS mount automatically gets the
# privilege level it needs without a separate manual flag.
privileged = builtins.any
(fs: fs.fsType == "nfs" || fs.fsType == "nfs4")
(builtins.attrValues config.fileSystems);
};
boot.loader = {