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

  1. Set fs_type explicitly in the volume capability to match what the plugin will validate (check plugin docs for supported/default fstypes)
  2. Check the full multierror for accompanying mount-flag mismatches and correct the whole capability spec
  3. Re-create/re-register the volume with the desired filesystem if the underlying volume was formatted differently
  4. 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

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


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