hardware.nvidia-container-toolkit.mounts: default mountOptions should include rprivate

Open Beginner friendly
#519,565 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
kubernetes, linux

Research direction

Start with nixos/modules/services/hardware/nvidia-container-toolkit/default.nix and inspect how the default mountOptions are passed to user-supplied mounts. Compare that path with the rprivate options emitted by nvidia-ctk cdi generate and verify the proposed default preserves per-entry overrides. Done means the default includes rprivate while users can still override mount options.

Written by the indexing model from the issue text.

Description

nixos/modules/services/hardware/nvidia-container-toolkit/default.nix defaults mountOptions to [ "ro" "nosuid" "nodev" "bind" ]. The mounts that nvidia-ctk cdi generate itself emits all carry rprivate (added in NVIDIA/nvidia-container-toolkit#980 for exactly the propagation reason below), so a user-supplied entry via this module ends up being the one mount in the resulting CDI spec without it.

Why it matters

When hostPath lives on a host filesystem in a shared peer group (the systemd default for /), the user-supplied mount lands in the container still shared. Any later rbind under that path — including nvidia-ctk's own auto-discovered per-library file mounts when the user-supplied entry is the driver lib directory — propagates to the host on the bind syscall. The per-file mount's own rprivate is applied as a second mount(MS_PRIVATE) call after the bind, so it only privatizes the container's copy; the host already received one. With a mountPropagation: Bidirectional hostPath of / elsewhere in the pod (a common shape for privileged node-level DaemonSets), each GPU-container start back-propagates ~30 overlay mounts onto the host's driver-lib paths, and a crash-looping container compounds it via the shared peer group until runc create returns ENOSPC at fs.mount-max.

Reproduce

NixOS host with hardware.nvidia-container-toolkit.enable = true, containerd runtime mode = "cdi", and:

hardware.nvidia-container-toolkit.mounts = [
  { hostPath = "${lib.getLib config.hardware.nvidia.package}/lib";
    containerPath = "/usr/local/nvidia/lib"; }
];

plus a Kubernetes pod that has mountPropagation: Bidirectional on a hostPath of / and NVIDIA_VISIBLE_DEVICES set. Restart that pod's container ~10 times; wc -l /proc/1/mountinfo on the host grows in 30·(2ⁿ−1) steps per nvidia .so path, all shared:N overlay entries.

Proposed change

Add "rprivate" to the default mountOptions — same rationale as nvidia-container-toolkit#980, applied to the module's injection path. Users who need shared propagation can still override per-entry.

   mountOptions = lib.mkOption {
     default = [
       "ro"
       "nosuid"
       "nodev"
       "bind"
+      "rprivate"
     ];

Happy to send the PR if this direction looks right.

Dominant language
Nix
Stars
26.2k
Forks
20.1k
Avg merge
14h 6m
Merged PRs (30d)
584

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NixOS/nixpkgs

All issues in NixOS/nixpkgs

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.