hashicorp/nomad · error

no task supports CSI

Error message

no task supports CSI

What it means

Nomad's CSI hook verifies that at least one task in the allocation's task group uses a driver whose capabilities include CSI mount support (MountConfigs != MountConfigSupportNone). If every task's driver reports no CSI mount capability, the client refuses to proceed with the volume claim/mount workflow, since no task could ever mount the requested CSI volumes.

Source

Thrown at client/allocrunner/csi_hook.go:240

// task driver that supports CSI. This prevents us from publishing CSI volumes
// only to find out once we get to the taskrunner/volume_hook that no task can
// mount them.
func (c *csiHook) validateTasksSupportCSI(tg *structs.TaskGroup) error {

	for _, task := range tg.Tasks {
		caps, err := c.allocRunnerShim.GetTaskDriverCapabilities(task.Name)
		if err != nil {
			return fmt.Errorf("could not validate task driver capabilities: %v", err)
		}

		if caps.MountConfigs == drivers.MountConfigSupportNone {
			continue
		}

		return nil
	}

	return fmt.Errorf("no task supports CSI")
}

// restoreMounts tries to restore the mount info from the local client state and
// then verifies it with the plugin. If the volume is already mounted, we don't
// want to re-run the claim and mount workflow again. This lets us tolerate
// restarting clients even on disconnected nodes.
func (c *csiHook) restoreMounts(results map[string]*volumePublishResult) error {
	stubs, err := c.allocRunnerShim.GetCSIVolumes()
	if err != nil {
		return err
	}
	if stubs == nil {
		return nil // no previous volumes
	}
	for _, result := range results {
		stub := stubs[result.request.Name]
		if stub == nil {
			continue

View on GitHub (pinned to 482b49bf1a)

Solutions

1. Ensure at least one task in the group runs with a CSI-capable driver (e.g. docker with mount_config support or an exec/raw_exec driver that supports CSI).
2. Upgrade the task driver / Nomad client so the driver reports MountConfigs support in its capabilities.
3. Remove the CSI volume blocks from the jobspec if the workload doesn't actually need them.
4. Verify the client's fingerprinted drivers with `nomad node status <node> -verbose` and confirm the driver is enabled and CSI-capable.

Example fix

// before: group has only a task whose driver can't mount CSI volumes
task "rawexec-loader" { driver = "raw_exec" }
volume "data" { type = "csi" ... }

// after: add a task using a CSI-capable driver (e.g. docker) that mounts the volume
task "app" {
  driver = "docker"
  volume_mount { volume = "data" destination = "/data" }
}

// before submitting/running, confirm at least one task driver supports CSI mounting
caps, err := driver.GetTaskDriverCapabilities(taskName)
if err != nil || caps == nil || caps.MountConfigs == drivers.MountConfigSupportNone {
    return fmt.Errorf("task %s driver cannot mount CSI volumes", taskName)
}

func supportsCSI(caps *drivers.Capabilities) bool {
    return caps != nil && caps.MountConfigs != drivers.MountConfigSupportNone
}

When it happens

Trigger: Prerun -> validateTasksSupportCSI: the job's task group declares CSI volume blocks, but GetTaskDriverCapabilities returns MountConfigSupportNone for every task in the group — e.g. the driver doesn't implement CSI mounting at all, or the driver advertises no mount-config capability on this client.

Common situations: Running a job with csi volumes on a client whose driver version is too old to support CSI (pre-CSI plugin drivers), or using a driver like docker/qemu that doesn't mount CSI volumes, after upgrading a Nomad client but not the task drivers, or scheduling a CSI-volume job onto clients where the CSI-capable driver is not enabled.

Related errors

• restoring mounts: %w
• claiming volumes: %w
• could not claim volume %s: %w
• No CSI Mount Point found for volume: %s
• Task group volume validation for %s failed: %v

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