hashicorp/nomad · error
'file-system' access type was not requested but was validate
Error message
'file-system' access type was not requested but was validated by the controller
What it means
In compareCapabilities, if the plugin validated a capability with a 'mount' (file-system) access type but the caller did not request a mount capability, Nomad appends this error. Like the block-device variant, it means the plugin validated capabilities outside the requested set, so validation results cannot be trusted as a match.
Source
Thrown at plugins/csi/client.go:599
}
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))
continue NEXT_CAP
}
for _, expectedFlag := range expectedMount.MountFlags {
// The mount flags can contain sensitive data, so we can't log exact
// details.
if !slices.Contains(capMount.MountFlags, expectedFlag) {
multierror.Append(&err, fmt.Errorf(
"requested mount flags did not match available capabilities"))View on GitHub (pinned to 482b49bf1a)
Solutions
- Add a mount/file-system capability to the request if filesystem usage is intended
- Verify with the plugin vendor that ControllerValidateVolumeCapabilities should only echo requested capabilities; upgrade/patch the plugin if it over-validates
- Re-register the volume with the correct access_type matching actual usage
- Re-run validation after the fix
Example fix
// before: only block-device requested
volume_capabilities = [{ access_type = "block-device", access_mode = "single-node-writer" }]
// after: request the mount capability explicitly if using a filesystem
volume_capabilities = [{ access_type = "mount", access_mode = "single-node-writer", fs_type = "ext4" }] Defensive patterns
Strategy: validation
Validate before calling
// ensure a mount capability is present in the request when the volume uses a filesystem
hasMount := false
for _, cap := range req.VolumeCapabilities {
if cap.GetMount() != nil { hasMount = true }
}
if !hasMount {
return errors.New("volume uses a filesystem but no mount capability was requested")
} Type guard
func onlyRequestedTypesValidated(expected, validated []*csipbv1.VolumeCapability) error {
for _, v := range validated {
if v.GetMount() != nil {
found := false
for _, e := range expected {
if e.GetMount() != nil { found = true }
}
if !found { return errors.New("file-system validated but not requested") }
}
}
return nil
} Try / catch
err := client.ControllerValidateCapabilities(ctx, req)
if err != nil {
if strings.Contains(err.Error(), "'file-system' access type was not requested") {
// add a mount capability to the request or fix the plugin
}
return err
} Prevention
- Declare access_type = "mount" whenever the consumer will mount a filesystem
- Do not reuse raw-block volume specs for filesystem-backed volumes
- Verify plugin strictness: it should only validate requested capabilities; upgrade otherwise
- Re-register the volume when changing access types and re-run validation
When it happens
Trigger: ControllerValidateCapabilities called with only block-device capabilities requested, but the plugin response includes a capability where GetMount() is non-nil, hitting expectedMount == nil after the capMount nil check.
Common situations: Registering a raw-block volume but the plugin (possibly misconfigured or buggy) validates filesystem capabilities too; plugin upgrade changed validation to be non-strict; mixing volume spec templates across drivers that behave differently.
Related errors
- 'block-device' access type was not requested but was validat
- 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/08419e0c4939ae77.
Report an issue: GitHub.