hashicorp/terraform · error · statemgr.LockError

lock id mismatch, %v != %v

Error message

lock id mismatch, %v != %v

What it means

Raised by remoteClient.Unlock() (cos/client.go:126) when the lock info's stored ID (the md5 checksum of the lock file) does not match the check value supplied to Unlock. You may only release a lock whose ID matches the one returned by your own Lock call.

Source

Thrown at internal/backend/remote-state/cos/client.go:126

	err = c.putObject(c.lockFile, data)
	if err != nil {
		return "", c.lockError(err)
	}

	return check, nil
}

// Unlock unlock remote state file
func (c *remoteClient) Unlock(check string) error {
	log.Printf("[DEBUG] unlock remote state file %s", c.lockFile)

	info, err := c.lockInfo()
	if err != nil {
		return c.lockError(err)
	}

	if info.ID != check {
		return c.lockError(fmt.Errorf("lock id mismatch, %v != %v", info.ID, check))
	}

	err = c.deleteObject(c.lockFile)
	if err != nil {
		return c.lockError(err)
	}

	err = c.cosUnlock(c.bucket, c.lockFile)
	if err != nil {
		return c.lockError(err)
	}

	return nil
}

// lockError returns statemgr.LockError
func (c *remoteClient) lockError(err error) *statemgr.LockError {
	log.Printf("[DEBUG] failed to lock or unlock %s: %v", c.lockFile, err)

View on GitHub (pinned to c9def3e214)

Solutions

  1. Use the exact lock ID reported in the original lock error message.
  2. Run `terraform force-unlock <correct-id>` with the ID shown by terraform.
  3. If no correct ID is known, inspect the lock file object to recover its md5 ID.

Example fix

// before: wrong id
terraform force-unlock 00000000
// after: id from the lock error
terraform force-unlock abc123def456
Defensive patterns

Strategy: validation

Validate before calling

// Confirm the supplied unlock ID matches the stored lock ID before unlocking
stored, err := c.lockInfo()
if err == nil && stored.ID != check {
    return fmt.Errorf("lock id mismatch, %v != %v", stored.ID, check)
}

Prevention

When it happens

Trigger: Unlock(check) reads lockInfo() and finds info.ID != check; e.g. calling force-unlock with the wrong ID, or the lock was replaced by a different holder.

Common situations: Using a stale or copied lock ID for force-unlock; the lock was already taken over by another process whose ID differs; checksum mismatch due to a rewritten lock file.

Related errors


AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/22020ea32c092c6f. Report an issue: GitHub.