hashicorp/nomad · error

requested runtime %q is not allowed

Error message

requested runtime %q is not allowed

What it means

The docker plugin maintains an allowlist of runtimes (allow_runtimes plugin config; historically allow_caps-style safety). If the resolved containerRuntime (task-specified, or GPU-derived) is not empty and not in d.config.allowRuntimes, container creation is rejected. This is a deliberate operator security control on which runtimes tasks may use.

Source

Thrown at drivers/docker/driver.go:1075

		OpenStdin:  driverConfig.Interactive,
	}

	if driverConfig.WorkDir != "" {
		config.WorkingDir = driverConfig.WorkDir
	}

	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

View on GitHub (pinned to 482b49bf1a)

Solutions

1. Add the desired runtime to the plugin's allow_runtimes in the Nomad client config and reload Nomad: allow_runtimes = ["runc", "sysbox-runc"].
2. Change the job's runtime option to one that is allowlisted (usually omit it and use the default runc).
3. Verify with `docker info` the runtime name spelled in the job exactly matches a registered runtime.

Example fix

// client plugin config
// before
plugin "docker" { config { allow_runtimes = ["runc"] } }
// after
plugin "docker" { config { allow_runtimes = ["runc", "nvidia"] } }

function validateRuntimeAllowed(runtime, allowedRuntimes) {
  if (runtime && !allowedRuntimes.includes(runtime)) {
    throw new Error(`runtime "${runtime}" is not in allow_runtimes: ${allowedRuntimes.join(', ')}`);
  }
}

try {
  await client.jobs.submit(job);
} catch (err) {
  if (/is not allowed/.test(err.message)) {
    console.error('Add runtime to plugin allow_runtimes or change the job');
  }
  throw err;
}

When it happens

Trigger: Job sets runtime = "sysbox-runc" (or any custom runtime) while the client plugin config does not include it in allow_runtimes; GPU runtime name itself not present in the allowlist after a config change.

Common situations: Operator configured allow_runtimes = ["runc"] but jobs use a kata/sysbox/gVisor runtime; plugin config rolled out without the new runtime name; renamed runtime after a Docker upgrade.

Related errors

• driver does not allow the following capabilities: %s
• running container as ContainerAdmin is unsafe; change the co
• volumes are not enabled; cannot mount host path: %q
• invalid security_opt: %q
• opening seccomp profile (%s) failed: %v

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