hashicorp/nomad · error

volumes are not enabled; cannot mount volume: %q

Error message

volumes are not enabled; cannot mount volume: %q

What it means

When docker volumes are disabled on the client (volumes.enabled=false), any mount whose type is not "bind" or "tmpfs" — typically type="volume" — is rejected outright in toDockerMount. Named Docker volumes are only permitted when the client operator has enabled them.

Source

Thrown at drivers/docker/driver.go:1628

	hm, err := m.toDockerHostMount()
	if err != nil {
		return nil, err
	}

	switch hm.Type {
	case "bind":
		hm.Source = expandPath(task.TaskDir().Dir, hm.Source)

		if !d.config.Volumes.Enabled {
			if err := escapingfs.ChildEscapesParentDir(task.AllocDir, hm.Source); err != nil {
				return nil, fmt.Errorf("volumes are not enabled; cannot mount host path: %q", hm.Source)
			}
		}
	case "tmpfs":
		// no source, so no sandbox check required
	default: // "volume", but also any new thing that comes along
		if !d.config.Volumes.Enabled {
			return nil, fmt.Errorf(
				"volumes are not enabled; cannot mount volume: %q", hm.Source)
		}
	}

	return &hm, nil
}

// detectIP of Docker container. Returns the first IP found as well as true if
// the IP should be advertised (bridge network IPs return false). Returns an
// empty string and false if no IP could be found.
func (d *Driver) detectIP(c mclient.ContainerInspectResult, driverConfig *TaskConfig) (string, bool) {
	if c.Container.NetworkSettings == nil {
		// This should only happen if there's been a coding error (such
		// as not calling InspectContainer after CreateContainer). Code
		// defensively in case the Docker API changes subtly.
		d.logger.Error("no network settings for container", "container_id", c.Container.ID)
		return "", false
	}

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Set volumes.enabled=true in the client's docker plugin config if named volumes are acceptable.
  2. Switch the mount to type="tmpfs" (in-memory) or a relative bind inside the alloc dir.
  3. Use a Nomad host_volume or CSI volume with explicit job-level allow-listing instead of a raw docker named volume.

Example fix

// before
mounts = [{ type = "volume", source = "mydata", target = "/data" }]
// after
# client.hcl: plugin "docker" { config { volumes { enabled = true } } }
# or use: mounts = [{ type = "tmpfs", target = "/data" }]
Defensive patterns

Strategy: validation

Validate before calling

// reject volume-type mounts when the target client has docker volumes disabled
if mountType == "volume" && !clientDockerVolumesEnabled {
    return fmt.Errorf("volume mount %q needs volumes.enabled=true on client", source)
}

Prevention

When it happens

Trigger: A task config declares a mount with type="volume" (or a novel type) while the client's docker plugin config has volumes.enabled=false.

Common situations: Jobs referencing named docker volumes on clients where the operator disabled them for security; copy-pasted job files from environments with volumes enabled.

Related errors


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