🚨 OpenTofu Error: 'Error acquiring the state lock' — Cause, Fix, and Troubleshooting Guide

What this error means

OpenTofu takes an advisory lock on your state before any operation that could write to it (plan with -refresh, apply, destroy, state subcommands). The lock stops two runs from mutating the same state at once. If another process holds the lock — or a previous run crashed and left it behind — tofu refuses to start:

Error: Error acquiring the state lock

Error message: ConditionalCheckFailedException: The conditional request failed
Lock Info:
  ID:        9f1c2b7a-3e4d-4a1b-9c2f-1a2b3c4d5e6f
  Path:      example-tofu-state/prod/terraform.tfstate
  Operation: OperationTypeApply
  Who:       runner@ci-node-7
  Version:   1.8.2
  Created:   2026-07-14 09:12:41.11 +0000 UTC

OpenTofu acquires a state lock to protect the state from being written
by multiple users at the same time. Please resolve the issue above and try
again. For most commands, you can disable locking with the "-lock=false"
flag, but this is not recommended.

Observed behaviour

• tofu apply/plan exits immediately with Error acquiring the state lock.
• The Lock Info block names a Who, Created timestamp, and Operation.
• Common in CI when a job is cancelled mid-apply and the lock is never released.
• Two pipelines (or a person and a pipeline) target the same state concurrently.

Storage and state causes

• Genuine concurrency — a second apply is legitimately running against the same state.
• Stale lock from a crash — a runner was killed (OOM, timeout, Ctrl-C twice) before releasing the lock.
• Backend lock table issue — DynamoDB table missing, wrong name, or throttled for the S3 backend.
• Clock/permission problems — the identity can read state but lacks permission to write the lock row.
• Shared state across environments — multiple stacks accidentally point at the same key.

Inspecting stored state

Read the full lock info — the Who and Created fields tell you if it is live or abandoned:

tofu plan 2>&1 | sed -n '1,25p'

For the S3 + DynamoDB backend, inspect the lock row directly:

aws dynamodb get-item \
  --table-name tofu-locks \
  --key '{"LockID":{"S":"example-tofu-state/prod/terraform.tfstate-md5"}}'

Confirm no other run is active before you break anything:

# Check CI: is another pipeline job still running against this state?
gh run list --workflow deploy.yml --limit 5

Resolution

If the lock is genuinely held, wait for the other run to finish, or add a bounded retry:

tofu apply -lock-timeout=120s

If the lock is stale (the owning run is long dead), force-unlock using the exact ID from the error:

tofu force-unlock 9f1c2b7a-3e4d-4a1b-9c2f-1a2b3c4d5e6f

Never routinely disable locking, but for a read-only local plan on a dev copy it is acceptable:

tofu plan -lock=false   # last resort, read-only, single operator only

Fix the backend if the lock table is missing (S3 backend requires DynamoDB):

aws dynamodb create-table \
  --table-name tofu-locks \
  --attribute-definitions AttributeName=LockID,AttributeType=S \
  --key-schema AttributeName=LockID,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

Protecting state integrity

• force-unlock only removes the lock; it does not roll back a half-written state. Verify state integrity with tofu plan afterward.
• Serialize CI: use concurrency groups so only one apply per state runs at a time.
• Set a sane -lock-timeout in automation so transient contention retries instead of failing instantly.
• Give each environment its own backend key — never share one state across stacks.
• Only force-unlock an ID you can prove is dead; unlocking a live run can corrupt state.

Related storage errors

• OpenTofu Error: ‘Backend configuration changed’ — Cause, Fix, and Troubleshooting Guide
• OpenTofu Error: ‘Error loading state: AccessDenied’ — Cause, Fix, and Troubleshooting Guide
• OpenTofu Error: ‘state snapshot was created by a newer version’ — Cause, Fix, and Troubleshooting Guide