lima-vm/lima · error

unsupported filesystem type %#q for fstab entry: %v

Error message

unsupported filesystem type %#q for fstab entry: %v

What it means

Raised by mountFSTabEntry when a syntactically valid 6-field mounts entry uses a filesystem type other than `virtiofs`. On macOS the fake cloud-init only implements virtiofs mounts (as symlinks into /Volumes/My Shared Files); any other fstype is rejected with the offending type and full entry in the message.

Source

Thrown at pkg/guestagent/fakecloudinit/fakecloudinit_darwin.go:155

	if len(userData.BootCmd) > 0 {
		logrus.Warn("bootcmd is not implemented")
	}
	return errors.Join(errs...)
}

// mountFSTabEntry mounts a filesystem based on the given fstab entry.
// The format mimics Linux's convention.
// The entries are not written to /etc/fstab.
func mountFSTabEntry(m []string) error {
	if len(m) != 6 {
		return fmt.Errorf("invalid fstab entry: expected 6 fields, got %d: %v", len(m), m)
	}
	src, dst, fsType := m[0], m[1], m[2]
	switch fsType {
	case "virtiofs":
		return mountVirtiofs(src, dst)
	default:
		return fmt.Errorf("unsupported filesystem type %#q for fstab entry: %v", fsType, m)
	}
}

// mountVirtiofs symlinks `/Volumes/My Shared Files/<pseudoTag>` (automatically mounted by macOS) to dir.
// dir must not exist, or, must be a symlink to the expected source.
func mountVirtiofs(pseudoTag, dir string) error {
	if strings.Contains(pseudoTag, string(filepath.Separator)) {
		return fmt.Errorf("invalid pseudo tag for virtiofs: %#q", pseudoTag)
	}
	lnSrc := filepath.Join("/Volumes/My Shared Files", pseudoTag)

	// FIXME: verify that the filesystem of lnSrc is indeed read-only when user-data contains the "ro" option.
	// unix.Statfs() could be used, but unix.Statfs_t.Flags & unix.MNT_RDONLY seems always 0 for virtiofs.
	// `mount -v` does not show "ro" flag either.

	lnExisting, err := os.Readlink(dir)
	if err == nil {
		if lnExisting == lnSrc {

View on GitHub (pinned to dd909d0973)

Solutions

1. Change the fstype field to exactly `virtiofs` (lowercase, no dash).
2. Share the host directory via Lima's virtiofs sharing so it appears under /Volumes/My Shared Files in the guest.
3. Remove the mounts entry if the filesystem type is not needed on macOS.
4. For non-virtiofs filesystems, configure the mount outside user-data (e.g. a boot script in /var/lib/cloud/scripts/per-boot).

Example fix

// before (user-data)
mounts:
  - ["/Users/foo/share", "/mnt/share", "9p", "ro", "0", "0"]
// after
mounts:
  - ["/Users/foo/share", "/mnt/share", "virtiofs", "ro", "0", "0"]

func validateFSType(mounts [][]string) error {
  for i, m := range mounts {
    if len(m) == 6 && m[2] != "virtiofs" {
      return fmt.Errorf("mounts[%d]: fstype %q unsupported on macOS (only virtiofs)", i, m[2])
    }
  }
  return nil
}

func isVirtiofsEntry(m []string) bool { return len(m) == 6 && m[2] == "virtiofs" }

if err := mountFSTabEntry(m); err != nil {
  if strings.Contains(err.Error(), "unsupported filesystem type") {
    log.Warnf("non-virtiofs mount skipped: %v", m)
    continue
  }
  return err
}

When it happens

Trigger: A mounts entry with fstype such as `9p`, `ext4`, `nfs`, `tmpfs`, or an empty string reaches mountFSTabEntry's switch default branch.

Common situations: Porting user-data from a Linux VM config that used 9p or other native mounts, typos like `virtio-fs` or `VirtioFS` (matching is exact, lowercase `virtiofs` only), or leftover mounts entries from a different hypervisor.

Related errors

• failed to mount fstab entry %v: %w
• invalid pseudo tag for virtiofs: %#q
• unexpected symlink target for virtiofs mount source %#q: exp
• failed to create symlink from %#q to %#q: %w
• field `mountType` must be %#q or %#q for QEMU driver on macO

AI-assisted analysis of lima-vm/lima@dd909d0973 (2026-09-01). Data as JSON: /api/errors/d389f8b8b955190c. Report an issue: GitHub.