Failed to create container configuration, cannot use isolati

Error message

Failed to create container configuration, cannot use isolation mode "%s" on %s

What it means

The `isolation` docker task option (process vs hyperv) is only meaningful on Windows. On non-Windows platforms, setting it to anything other than empty is rejected with this error. On Windows, an empty isolation defaults to hyperv and must be one of the supported modes.

Source

Thrown at drivers/docker/driver.go:1081

	containerRuntime := driverConfig.Runtime
	if _, ok := task.DeviceEnv[nvidiaVisibleDevices]; ok {
		if !d.gpuRuntime {
			return c, fmt.Errorf("requested docker runtime %q was not found", d.config.GPURuntimeName)
		}
		if containerRuntime != "" && containerRuntime != d.config.GPURuntimeName {
			return c, fmt.Errorf("conflicting runtime requests: gpu runtime %q conflicts with task runtime %q", d.config.GPURuntimeName, containerRuntime)
		}
		containerRuntime = d.config.GPURuntimeName
	}
	if _, ok := d.config.allowRuntimes[containerRuntime]; !ok && containerRuntime != "" {
		return c, fmt.Errorf("requested runtime %q is not allowed", containerRuntime)
	}

	// Validate isolation modes on windows
	if runtime.GOOS != "windows" {
		if driverConfig.Isolation != "" {
			return c, fmt.Errorf("Failed to create container configuration, cannot use isolation mode \"%s\" on %s", driverConfig.Isolation, runtime.GOOS)
		}
	} else {
		if driverConfig.Isolation == "" {
			driverConfig.Isolation = windowsIsolationModeHyperV
		}
		if !slices.Contains(windowsIsolationModes, driverConfig.Isolation) {
			return c, fmt.Errorf("Unsupported isolation mode \"%s\"", driverConfig.Isolation)
		}
	}

	var pidsLimit int64 = -1 // default unlimited

	// Pids limit defined in Nomad plugin config.
	if d.config.PidsLimit > 0 {
		pidsLimit = d.config.PidsLimit
	}

	// Override Nomad plugin config pids limit, by user defined pids limit.

View on GitHub (pinned to 482b49bf1a)

Solutions

Remove the `isolation` field from the docker task config (it only applies to Windows).
Add `constraint { attribute = "${attr.kernel.name}" = "windows" }` if the job genuinely needs Windows isolation semantics.
Parameterize the job template so isolation is only rendered for Windows targets.

Example fix

// task docker config
// before
isolation = "hyperv"
// after
// (remove isolation line on Linux)

Defensive patterns

Strategy: validation

Validate before calling

function validateIsolationForPlatform(isolation, kernelName) {
  if (kernelName !== 'windows' && isolation) {
    throw new Error(`isolation option is only valid on Windows, got "${isolation}"`);
  }
}

Try / catch

try {
  await client.jobs.submit(job);
} catch (err) {
  if (/cannot use isolation mode/.test(err.message)) {
    console.error('Remove isolation from the task or constrain the job to Windows clients');
  }
  throw err;
}

Prevention

Add a Windows kernel constraint to jobs that use the isolation option.
Keep isolation out of shared multi-OS job templates.
Template-render isolation only when the target datacenter/clients are Windows.

When it happens

Trigger: A job with `isolation = "hyperv"` (or "process") in the docker task config is scheduled onto a Linux client; runtime.GOOS != "windows" makes any non-empty isolation invalid.

Common situations: Job spec written for Windows clients reused in a mixed-OS datacenter without constraints; copy-pasted docker config template carrying isolation everywhere.

Related errors

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