hashicorp/nomad · error

Task group volume validation for %s failed: %v

Error message

Task group volume validation for %s failed: %v

What it means

TaskGroup.Validate runs VolumeRequest.Validate (with job type, group count, and canary count) for every entry in the group's `volume` map and wraps any failure with the volume's name in this message, appended to the job multierror. It signals a misconfigured host/CSI volume request at the task-group level.

Source

Thrown at nomad/structs/structs.go:7287

	if leaderTasks > 1 {
		mErr = multierror.Append(mErr, fmt.Errorf("Only one task may be marked as leader"))
	}

	// A task group made up entirely of lifecycle tasks (prestart, poststart, or
	// poststop) has no main task to run, which is invalid.
	if len(tg.Tasks) > 0 && mainTasks == 0 {
		mErr = multierror.Append(mErr, fmt.Errorf("Task group %s must have at least one main task", tg.Name))
	}

	// Validate the volume requests
	var canaries int
	if tg.Update != nil {
		canaries = tg.Update.Canary
	}
	for name, volReq := range tg.Volumes {
		if err := volReq.Validate(j.Type, tg.Count, canaries); err != nil {
			mErr = multierror.Append(mErr, fmt.Errorf(
				"Task group volume validation for %s failed: %v", name, err))
		}
	}

	// Validate task group and task network resources
	if err := tg.validateNetworks(); err != nil {
		outer := fmt.Errorf("Task group network validation failed: %v", err)
		mErr = multierror.Append(mErr, outer)
	}

	// Validate task group and task services
	if err := tg.validateServices(); err != nil {
		outer := fmt.Errorf("Task group service validation failed: %v", err)
		mErr = multierror.Append(mErr, outer)
	}

	// Validate group service script-checks
	if err := tg.validateScriptChecksInGroupServices(); err != nil {

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Read the wrapped inner %v error and fix the specific field in the named group `volume` block.
  2. Verify the `source` matches a registered host_volume in client config or a registered CSI volume/plugin id.
  3. Check type-specific constraints (e.g. access_mode/mount_options for CSI, per_alloc restrictions).

Example fix

// before
volume "data" {
  type = "host"
  # source missing
}
// after
volume "data" {
  type = "host"
  source = "shared-data"
}
Defensive patterns

Strategy: validation

Validate before calling

// Go: validate volume requests before submission
for name, vol := range tg.Volumes {
  if vol.Type == "host" && vol.Source == "" {
    return fmt.Errorf("group volume %q: host volume requires source", name)
  }
  if vol.Type == "csi" && vol.Source == "" {
    return fmt.Errorf("group volume %q: csi volume requires source (volume id)", name)
  }
}

Prevention

When it happens

Trigger: Submitting a job whose group `volume` block fails validation — e.g. missing required `source` for a host_volume/CSI type, invalid `type`, mount options incompatible with the volume, or count/canary constraints on read-only/CSI volumes.

Common situations: Referencing a host volume name typo'd or absent from the client config; mixing csi vs host volume fields; setting per_alloc on CSI volumes; Docker driver-only mount syntax errors.

Related errors


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