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

  1. Add a mount/file-system capability to the request if filesystem usage is intended
  2. Verify with the plugin vendor that ControllerValidateVolumeCapabilities should only echo requested capabilities; upgrade/patch the plugin if it over-validates
  3. Re-register the volume with the correct access_type matching actual usage
  4. 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

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


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