hashicorp/nomad · error

No CSI Mount Point found for volume: %s

Error message

No CSI Mount Point found for volume: %s

What it means

In prepareCSIVolumes, the hook maps each task volume_mount alias to a CSI mount point that the client computed earlier (from the allocation's volumes and CSI node publishing). If the alias declared in the task's volume_mount stanza has no corresponding entry in csiMountPoints, Prestart fails. This means the task references a volume that was never staged/published for this allocation or was named incorrectly.

Source

Thrown at client/allocrunner/taskrunner/volume_hook.go:184

func (h *volumeHook) prepareCSIVolumes(req *interfaces.TaskPrestartRequest, volumes map[string]*structs.VolumeRequest) ([]*drivers.MountConfig, error) {
	if len(volumes) == 0 {
		return nil, nil
	}

	var mounts []*drivers.MountConfig

	mountRequests := partitionMountsByVolume(req.Task.VolumeMounts)
	csiMountPoints := h.runner.allocHookResources.GetCSIMounts()
	for alias, request := range volumes {
		mountsForAlias, ok := mountRequests[alias]
		if !ok {
			// This task doesn't use the volume
			continue
		}

		csiMountPoint, ok := csiMountPoints[alias]
		if !ok {
			return nil, fmt.Errorf("No CSI Mount Point found for volume: %s", alias)
		}

		for _, m := range mountsForAlias {
			mcfg := &drivers.MountConfig{
				RequestName:     request.Name,
				HostPath:        csiMountPoint.Source,
				TaskPath:        m.Destination,
				Readonly:        request.ReadOnly || m.ReadOnly,
				PropagationMode: m.PropagationMode,
				SELinuxLabel:    m.SELinuxLabel,
			}
			mounts = append(mounts, mcfg)
		}
	}

	if len(mounts) > 0 {
		caps, err := h.runner.DriverCapabilities()
		if err != nil {

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Make the volume_mount volume name exactly match the group-level volume declaration (volume "name" { type = "csi" ... })
  2. Check CSI volume health and per-alloc events: nomad volume status <id>, and fix the failing CSI plugin/stage-publish step
  3. Ensure the target client node has a running, registered CSI plugin that supports the volume's filesystem/access mode
  4. Re-run or reschedule the allocation after the CSI controller/node publish succeeds

Example fix

// before
volume "db" { type = "csi" source = "ebs-0" }
task "app" { volume_mount { volume = "database" } } // typo
// after
task "app" { volume_mount { volume = "db" } }
Defensive patterns

Strategy: validation

Validate before calling

// Validate at job-authoring time: every task volume_mount name must match a group volume
taskMounts := map[string]bool{}
for _, m := range task.VolumeMounts { taskMounts[m.Volume] = true }
for name := range taskMounts {
    if _, ok := group.Volumes[name]; !ok || group.Volumes[name].Type != "csi" {
        return fmt.Errorf("task %q mounts undeclared CSI volume %q", task.Name, name)
    }
}
// Also check publication health before deploy: nomad volume status <source>

Prevention

When it happens

Trigger: Task's volume_mount stanza uses a volume name that does not match any group-level volume declaration with type = "csi", or the group CSI volume exists but the client never obtained a mount point for it (missing csi_mount_point entry in csiMountPoints map for that alias), e.g. the volume was not successfully published/staged by the CSI plugin for this node.

Common situations: Typo in the volume name inside volume_mount (name mismatch with the group volume block); CSI volume failed to stage/publish earlier (plugin error) so the mount point is absent; job updated to reference a CSI volume on a node whose CSI plugin didn't register; copying a job between clusters where the CSI volume doesn't exist.

Related errors


AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04). Data as JSON: /api/errors/61f86fbb98fbc3d1. Report an issue: GitHub.