hashicorp/nomad · error

'block-device' access type was not requested but was validat

Error message

'block-device' access type was not requested but was validated by the controller

What it means

In compareCapabilities, if the controller plugin validated a capability with a 'block' (block-device) access type but the caller never requested block access, Nomad appends this error. It indicates the plugin validated more (or different) capabilities than were requested, so the requested set cannot be considered verified.

Source

Thrown at plugins/csi/client.go:589

		capMode := cap.GetAccessMode().GetMode()

		// The plugin may not validate AccessMode, in which case we'll
		// get UNKNOWN as our response
		if capMode != csipbv1.VolumeCapability_AccessMode_UNKNOWN {
			if expectedMode != capMode {
				multierror.Append(&err,
					fmt.Errorf("requested access mode %v, got %v", expectedMode, capMode))
				continue NEXT_CAP
			}
		}

		capBlock := cap.GetBlock()
		capMount := cap.GetMount()
		expectedBlock := expected.GetBlock()
		expectedMount := expected.GetMount()

		if capBlock != nil && expectedBlock == nil {
			multierror.Append(&err, fmt.Errorf(
				"'block-device' access type was not requested but was validated by the controller"))
			continue NEXT_CAP
		}

		if capMount == nil {
			continue NEXT_CAP
		}

		if expectedMount == nil {
			multierror.Append(&err, fmt.Errorf(
				"'file-system' access type was not requested but was validated by the controller"))
			continue NEXT_CAP
		}

		if expectedMount.FsType != capMount.FsType {
			multierror.Append(&err, fmt.Errorf(
				"requested filesystem type %v, got %v",
				expectedMount.FsType, capMount.FsType))

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Add an explicit block-device capability to the request if block access is actually intended
  2. If only filesystem access is wanted, file a bug/check the plugin — it should not validate capabilities that were not requested
  3. Upgrade or downgrade the plugin to a version whose validation matches the request
  4. Re-run validation after correcting either the request or the plugin

Example fix

// before: only mount capability requested, plugin also validates block
volume_capabilities = [{ access_type = "mount", access_mode = "single-node-writer" }]
// after: either add block or fix plugin; to request block explicitly
volume_capabilities = [{ access_type = "block-device", access_mode = "single-node-writer" }]
Defensive patterns

Strategy: validation

Validate before calling

// ensure request only contains access types the volume will actually use
for _, cap := range req.VolumeCapabilities {
    if cap.GetBlock() == nil && cap.GetMount() == nil {
        return errors.New("capability must set either mount or block access type")
    }
}
// if raw block is not intended, do not register block-device capabilities

Type guard

func onlyRequestedTypesValidated(expected, validated []*csipbv1.VolumeCapability) error {
    for _, v := range validated {
        if v.GetBlock() != nil {
            found := false
            for _, e := range expected {
                if e.GetBlock() != nil { found = true }
            }
            if !found { return errors.New("block-device validated but not requested") }
        }
    }
    return nil
}

Try / catch

err := client.ControllerValidateCapabilities(ctx, req)
if err != nil {
    if strings.Contains(err.Error(), "'block-device' access type was not requested") {
        // plugin over-validates: verify plugin version or add block capability
    }
    return err
}

Prevention

When it happens

Trigger: ControllerValidateCapabilities receives a request containing only mount-type capabilities, but the plugin's ControllerValidateVolumeCapabilities response includes a capability whose GetBlock() is non-nil, triggering capBlock != nil && expectedBlock == nil.

Common situations: A buggy or permissive plugin that blanket-accepts all capabilities regardless of the request; switching a volume from raw block device to filesystem mount without re-registering; plugin version upgrade changing validation behavior.

Related errors


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