hashicorp/nomad · error
requested filesystem type %v, got %v
Error message
requested filesystem type %v, got %v
What it means
In compareCapabilities, when both expected and validated capabilities are mount-type, Nomad compares FsType. If the filesystem type the plugin validated differs from the requested one, it appends 'requested filesystem type %v, got %v'. This means the driver validated the volume for a different filesystem than the job requires.
Source
Thrown at plugins/csi/client.go:605
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"))
continue NEXT_CAP
}
}
return nil
}View on GitHub (pinned to 482b49bf1a)
Solutions
- Set fs_type explicitly in the volume capability to match what the plugin will validate (check plugin docs for supported/default fstypes)
- Check the full multierror for accompanying mount-flag mismatches and correct the whole capability spec
- Re-create/re-register the volume with the desired filesystem if the underlying volume was formatted differently
- If the plugin ignores fs_type, upgrade the plugin or omit fs_type and accept the plugin default
Example fix
// before
capability { access_type = "mount" access_mode = "single-node-writer" }
// after: fs_type now explicit and matching the plugin's supported value
capability { access_type = "mount" access_mode = "single-node-writer" fs_type = "ext4" } Defensive patterns
Strategy: validation
Validate before calling
// confirm fs_type is set and supported by the driver before validating
supported := map[string]bool{"ext4": true, "xfs": true} // per driver docs
for _, cap := range req.VolumeCapabilities {
m := cap.GetMount()
if m != nil && m.GetFsType() != "" && !supported[m.GetFsType()] {
return fmt.Errorf("fs_type %q not supported by driver", m.GetFsType())
}
} Type guard
func fsTypeMatches(expected, validated *csipbv1.VolumeCapability) bool {
em, vm := expected.GetMount(), validated.GetMount()
if em == nil || vm == nil { return true }
return em.GetFsType() == vm.GetFsType()
} Try / catch
err := client.ControllerValidateCapabilities(ctx, req)
if err != nil {
if merr, ok := err.(*multierror.Error); ok {
for _, e := range merr.Errors {
if strings.Contains(e.Error(), "requested filesystem type") {
// align fs_type in the spec with the plugin's validated value
}
}
}
return err
} Prevention
- Always set fs_type explicitly in mount capabilities; never rely on driver defaults
- Check the driver's supported fstype list before changing it in the volume spec
- Remember filesystem is fixed at volume creation; changing fs_type later requires re-creating the volume
- Include fs_type consistency checks in CI for volume spec files
When it happens
Trigger: ControllerValidateCapabilities request includes a mount capability with fs_type (e.g. "xfs") but the plugin's validated capability reports a different fs_type (e.g. "ext4" or empty), causing expectedMount.FsType != capMount.FsType.
Common situations: Driver does not honor fs_type and defaults to its own filesystem; job spec fs_type changed after volume creation but the plugin validates against the volume's actual filesystem; empty fs_type in the spec being validated as the plugin default; plugin version upgrade changing default fstype handling.
Related errors
- missing TargetPath
- mount point detection failed for volume (%s): %v
- CSIPluginConfig StagePublishBaseDir must not be a subdirecto
- missing secret ID
- CSI.ControllerValidateVolume: VolumeID is required
AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04).
Data as JSON: /api/errors/08a0f8dd2c0dad17.
Report an issue: GitHub.