Fix Terraform State Lock Conflict Error

You're running terraform plan or terraform apply and it just sits there. Then you get the error: AcquireStateLock failed: Error acquiring the state lock. Yeah, that's annoying. Another process or someone else has the lock and your command can't proceed. Let's get you back to work.

The Direct Fix: Force-Unlock

The fastest way out is to force-unlock the state. But you need the lock ID first. Here's how:

Open a terminal in your Terraform project directory.
Run:
```
terraform force-unlock -force
```
Wait — you'll see an error: Lock ID is required. That's normal. You need the actual lock ID.
To get the lock ID, run:
```
terraform plan
```
It will fail again, but this time look at the error message. You'll see something like: Lock Info: ID: 12345678-1234-1234-1234-123456789abc Path: terraform.tfstate Operation: OperationTypeApply Who: your-user@company.com Version: 1.5.0 Created: 2025-03-15 14:32:10.123456789 +0000 UTC

Copy that ID value — the long string of letters and numbers with dashes.

Now run:

terraform force-unlock -force 12345678-1234-1234-1234-123456789abc

Replace the example ID with the one you copied.

You'll see: Terraform state has been successfully unlocked!
Run terraform plan again. It should work now.

A warning: Force-unlock is safe if you're sure no other Terraform process is actually running. If you force-unlock while someone else's terraform apply is mid-step, you'll corrupt the state file. Always check with your team first.

Why This Happens

Terraform uses a lock to stop two people from changing the state file at the same time. When you run terraform apply, it grabs a lock on the state file. If the process crashes, gets killed, or someone closes their terminal mid-apply, that lock doesn't get released. The lock stays in the backend — whether it's S3 with DynamoDB, Azure Storage, or Terraform Cloud.

The lock isn't on the file itself. It's a record in a separate database (like DynamoDB) that says "this lock ID is active." So even if you delete the state file and re-upload it, the lock remains. You have to remove that lock record. That's exactly what force-unlock does.

Less Common Variations of This Issue

Lock Stuck After CI/CD Pipeline Failure

This happens a lot with GitHub Actions or GitLab CI. The pipeline runs terraform apply, the runner gets killed (timeout, OOM, network drop), and the lock stays. Same fix — grab the lock ID from the pipeline logs, then force-unlock from your local machine.

Lock Shows From a Different Backend Path

Sometimes you get a lock error but the state file path looks wrong. For example, the lock says Path: /some/other/project/terraform.tfstate. This usually means you're using a shared backend (like the same S3 bucket) but with different workspace names. The lock is tied to the workspace. Check your workspace with terraform workspace show. If it's not what you expect, switch to the correct workspace: terraform workspace select your-workspace. Then force-unlock.

Lock ID Not Showing in Error Message

Rare, but happens with Terraform 0.12 and older. In that case, run:

terraform state list

and look at the debug output. Or check your backend's lock table directly. For S3/DynamoDB, go to the DynamoDB table (default name terraform-lock), find the item with the LockID matching your state file path, and delete it manually. That's the nuclear option — only do this if you're 100% sure no one is running Terraform.

How to Prevent This From Happening Again

Always use terraform apply -auto-approve only in CI. On your local machine, always review the plan before applying. If you need to cancel mid-apply, use Ctrl+C carefully. Wait for the cleanup message.

Set a lock timeout in your backend config. For S3 backend, in your backend.tf add:

terraform {
  backend "s3" {
    bucket         = "my-bucket"
    key            = "state/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Then, in your provider or Terraform block, set a shorter lock timeout:

terraform {
  required_version = ">= 1.0"
}

provider "aws" {
  region = "us-east-1"
  # This doesn't set lock timeout directly. Instead, use environment variable:
  # export TF_LOG=DEBUG
  # export TF_LOCK_TIMEOUT=5m
}

The lock timeout (default 10 minutes) can be changed with TF_LOCK_TIMEOUT environment variable. Set it to 5 minutes to avoid long waits if a lock is stuck.

Use Terraform Cloud or TFE for team workflows. They handle locks much better than S3 backends. If one apply fails, the lock auto-releases after a few minutes.
Never kill a terminal while Terraform is applying. Wait for it to finish. If you must kill it, do it with two Ctrl+C presses — the first one signals Terraform to release the lock, the second one force-kills after 10 seconds.

That's it. You're now unstuck and ready to go. Next time you see that lock error, you'll know exactly what to do — and hopefully won't see it as often.