lima-vm/lima · error

failed to lock disk %#q: %w

Error message

failed to lock disk %#q: %w

What it means

After passing the in-use check, Cmdline locks the disk for this instance via disk.Lock(inst.Dir). If the lock operation fails (stale lock files, permission problems on the disk directory, or concurrent lock contention), the error is wrapped as `failed to lock disk %#q: %w` and instance start aborts.

Source

Thrown at pkg/driver/krunkit/krunkit_darwin_arm64.go:72

	if inst.Config.SSH.OverVsock != nil && *inst.Config.SSH.OverVsock {
		sshVsockPath := filepath.Join(inst.Dir, sshVsockSock)
		args = append(args, "--device", fmt.Sprintf("virtio-vsock,port=22,socketURL=%s,connect", sshVsockPath))
	}

	// Add additional disks
	if len(inst.Config.AdditionalDisks) > 0 {
		ctx := context.Background()
		diskUtil := proxyimgutil.NewDiskUtil(ctx)
		for _, d := range inst.Config.AdditionalDisks {
			disk, derr := store.InspectDisk(d.Name, d.FSType)
			if derr != nil {
				return nil, fmt.Errorf("failed to load disk %#q: %w", d.Name, derr)
			}
			if disk.Instance != "" {
				return nil, fmt.Errorf("failed to run attach disk %#q, in use by instance %#q", disk.Name, disk.Instance)
			}
			if lerr := disk.Lock(inst.Dir); lerr != nil {
				return nil, fmt.Errorf("failed to lock disk %#q: %w", d.Name, lerr)
			}
			extraDiskPath := filepath.Join(disk.Dir, filenames.DataDisk)
			logrus.Infof("Mounting disk %#q on %#q", disk.Name, disk.MountPoint)
			if cerr := diskUtil.Convert(ctx, raw.Type, extraDiskPath, extraDiskPath, nil, true); cerr != nil {
				return nil, fmt.Errorf("failed to convert extra disk %#q to raw: %w", extraDiskPath, cerr)
			}
			args = append(args, "--device", fmt.Sprintf("virtio-blk,path=%s,format=raw", extraDiskPath))
		}
	}

	// Network commands
	networkArgs, err := buildNetworkArgs(inst)
	if err != nil {
		return nil, fmt.Errorf("failed to build network arguments: %w", err)
	}

	// File sharing commands
	if *inst.Config.MountType == limatype.VIRTIOFS {

View on GitHub (pinned to dd909d0973)

Solutions

1. Check the wrapped `%w` error; if it indicates a stale lock, run `limactl disk undeploy <disk>` then retry the start.
2. Fix permissions on ~/.lima/disks/<name> so the current user can write lock files.
3. Ensure no other limactl/VM process is concurrently starting an instance that shares this disk.
4. Move LIMA_HOME off network filesystems that break file locking.

Example fix

// before
$ limactl start myinstance   // fails: failed to lock disk "data"
// after
$ limactl disk undeploy data
$ limactl start myinstance

// Shell: ensure disk dir is writable and no stale lock before start
test -w "$HOME/.lima/disks/<name>" || { echo "disk dir not writable"; exit 1; }
limactl disk undeploy <name> 2>/dev/null || true

if err := inst.Start(ctx); err != nil {
    if strings.Contains(err.Error(), "failed to lock disk") {
        _ = exec.Command("limactl", "disk", "undeploy", diskName).Run()
        return inst.Start(ctx)
    }
    return err
}

When it happens

Trigger: Calling Start/Cmdline on an instance with additionalDisks when the disk's lock file cannot be acquired — e.g. leftover lock from a crashed VM, read-only or permission-denied ~/.lima/disks/<name>, or a race where another process locks the disk first.

Common situations: After a hard crash/kill -9 of limactl or the VM process leaving locks behind; running Lima instances under different users; syncing the Lima home via a filesystem that doesn't honor locks (some network mounts).

Related errors

• failed to run attach disk %#q, in use by instance %#q
• failed to load disk %#q: %w
• failed to convert extra disk %#q to raw: %w
• unimplemented by the krunkit driver
• failed to build network arguments: %w

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