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
- Add an explicit block-device capability to the request if block access is actually intended
- If only filesystem access is wanted, file a bug/check the plugin — it should not validate capabilities that were not requested
- Upgrade or downgrade the plugin to a version whose validation matches the request
- 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
- Only declare access_type = "block-device" in the volume spec when raw block is truly used
- Keep mount and block capabilities mutually consistent with the volume's usage
- Report plugins that validate unrequested capabilities to the vendor; pin a known-good plugin version
- Re-validate after any change to the volume's access type
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
- 'file-system' access type was not requested but was validate
- missing secret ID
- CSI.ControllerValidateVolume: VolumeID is required
- CSI.ControllerValidateVolume: PluginID is required
- CSI.ControllerAttachVolume: VolumeID is required
AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04).
Data as JSON: /api/errors/fc6a4ccd1dc67421.
Report an issue: GitHub.