lima-vm/lima · error

failed to sync back the changes from guest instance to host:

Error message

failed to sync back the changes from guest instance to host: %w

What it means

After the interactive shell exits, limactl syncs changes made inside the guest's synced workdir back to the original host directory via rsyncDirectory. This error wraps a failure of that guest->host rsync. When it occurs, the guest synced workdir is intentionally NOT cleaned up, so changes remain recoverable at destRsyncDir in the guest.

Source

Thrown at cmd/limactl/shell.go:551

		return shell
	}
	return `"` + shell + `"`
}

func askUserForRsyncBack(ctx context.Context, cmd *cobra.Command, inst *limatype.Instance, sshCmd *exec.Cmd, hostCurrentDir, destRsyncDir string, rsync copytool.CopyTool, tty bool) error {
	remoteSource := fmt.Sprintf("%s:%s", inst.Name, destRsyncDir)
	clean := filepath.Clean(hostCurrentDir)
	dirForCleanup := shellescape.Quote(filepath.Join(*inst.Config.User.Home, clean))
	cleanupGuestWorkdir := false

	rsyncBack := func() error {
		paths := []string{
			remoteSource,
			hostCurrentDir,
		}

		if err := rsyncDirectory(ctx, cmd, rsync, paths); err != nil {
			return fmt.Errorf("failed to sync back the changes from guest instance to host: %w", err)
		}
		logrus.Info("Successfully synced back the changes to host.")
		cleanupGuestWorkdir = true
		return nil
	}

	defer func() {
		if !cleanupGuestWorkdir {
			return
		}
		// Clean up the guest synced workdir
		if err := executeSSHForRsync(ctx, *sshCmd, inst.SSHLocalPort, inst.SSHAddress, fmt.Sprintf("rm -rf %s", dirForCleanup)); err != nil {
			logrus.WithError(err).Warn("Failed to clean up guest synced workdir")
		}
	}()

	if !tty {
		return rsyncBack()

View on GitHub (pinned to dd909d0973)

Solutions

  1. Recover changes from the guest workdir: `limactl shell <instance> ls <destRsyncDir>` then manually rsync/scp them out, since cleanup was skipped.
  2. Ensure the original host directory still exists and is writable, then re-run `limactl shell <instance>` and accept the changes again.
  3. Fix host-side permissions on hostCurrentDir (chown/chmod) and retry.
  4. Check rsync versions on both sides match and are >= 3.2.4; upgrade the older side.
  5. Review the wrapped rsync stderr (printed by rsyncDirectory) for the exact cause (e.g. 'connection unexpectedly closed').

Example fix

// before
if err := rsyncDirectory(ctx, cmd, rsync, paths); err != nil {
    return fmt.Errorf("failed to sync back the changes from guest instance to host: %w", err)
}
// after: guard that the destination exists before syncing back
if _, err := os.Stat(hostCurrentDir); err != nil {
    if mkErr := os.MkdirAll(hostCurrentDir, 0o755); mkErr != nil {
        return fmt.Errorf("host dir %s unavailable: %w (guest copy preserved at %s)", hostCurrentDir, mkErr, destRsyncDir)
    }
}
if err := rsyncDirectory(ctx, cmd, rsync, paths); err != nil {
    return fmt.Errorf("failed to sync back the changes from guest instance to host: %w", err)
}
Defensive patterns

Strategy: validation

Validate before calling

test -d "$PWD" && test -w "$PWD" && echo 'host dir writable, safe to sync back' || echo 'host dir missing or read-only: changes kept in guest at synced workdir'

Try / catch

// if the error occurs, changes are NOT lost — recover from the guest
limactl shell default || true
limactl shell default -- ls /home/<user>.lima/<basename-of-hostdir>  # inspect preserved workdir

Prevention

When it happens

Trigger: User confirmed "Yes" to accepting changes (or the session is non-TTY, where rsyncBack runs unconditionally) and rsyncDirectory from `instance:destRsyncDir` back to hostCurrentDir fails: SSH failure, host directory permissions, files deleted/replaced concurrently on the host, or rsync protocol mismatch.

Common situations: Host directory was deleted or renamed while the shell session was open, so the rsync destination vanished; host files became read-only or owned by another user; network/ssh multiplexing dropped for long sessions; rsync version mismatch between host and guest after a lima/OS upgrade.

Related errors


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