In this article, we’ll explain how Terraform state locking works, what usually causes the Error acquiring the state lock message, and how to resolve it safely.
How Terraform state locking works
Terraform uses your backend to lock the state before it performs operations that can change state, such as apply, destroy, or import. If the lock is available, Terraform acquires it, runs the operation, writes the updated state, and then releases the lock. This happens automatically for operations that could write state, if the backend supports locking.
If the lock is already held, Terraform stops and shows a state lock error so you do not risk state corruption.
When another run is already holding the lock, Terraform fails safely. The error message usually includes lock details such as who created the lock and when. This commonly happens when two CI pipelines target the same environment at the same time.
What causes the “Error acquiring the state lock” in Terraform?
Terraform shows Error acquiring the state lock when it cannot acquire the lock for the current state. In most cases, Terraform is protecting you from concurrent writes, or your backend cannot complete the locking operation.
- Another Terraform run is already using the state – This happens when someone is running
terraform apply,terraform destroy,terraform import, or a CI job against the same state path. Terraform refuses to continue so it does not corrupt the state. - A stale lock was left behind – A previous run can crash or get interrupted because of a killed terminal session, a failed CI runner, or a network drop. The lock remains even though nothing is actively running.
- Backend permissions are missing or too limited – Terraform needs permission to read and write state and to use whatever lock mechanism your backend relies on. Examples include: for AWS S3, verify access to the state object and, if locking is enabled, the lock file or legacy DynamoDB lock table, Azure Blob requires access to the blob and lease operations, and Google Cloud Storage requires permission to read and write the state object. If Terraform cannot create or update the lock or access the state correctly, it fails with a lock error.
- Backend connectivity or transient service issues – If Terraform cannot reliably reach the backend, it may fail while trying to acquire the lock. Common examples include VPN drops, DNS problems, proxy issues, cloud API throttling, or temporary service outages.
- Lock table or lock storage is misconfigured – This is especially common in AWS environments. Typical examples include a missing lock file setup or DynamoDB table, the wrong table name, the wrong region, or a backend configuration that points to a different workspace or key than expected.
- You are using local state or a backend that does not support locking in your setup – The local backend can lock state on the current machine, but it is not a good shared setup for teams because the state is still local. Some remote storage setups also do not lock unless they are configured correctly.
How to fix Terraform state lock errors
Terraform state lock errors happen when Terraform cannot get exclusive access to the state. The fix is usually either waiting for an active run to finish or safely removing a stale lock.
1. Check whether another Terraform run is active
The most common cause of Error acquiring the state lock is a valid lock held by another Terraform run. This often happens when a CI pipeline is still running, a previous job is stuck, or someone else is deploying to the same workspace.
Start by checking your CI or remote run history to see whether anything is targeting the same backend and state. If you run Terraform locally, also make sure you do not have another terminal session still running Terraform.
ps aux | grep terraform
If the error output includes lock details, use them to identify the owner, operation type, and timestamp. That is your best clue for deciding whether to wait or investigate further.
If another run is active, let it finish or stop it cleanly instead of forcing the lock immediately.
2. Identify whether the lock is stale
A stale Terraform state lock usually means a previous run crashed or was terminated before it could release the lock. The important question is whether anyone is still legitimately using the state.
Look closely at the lock details in the error message. They usually include who created the lock and when. Compare that information with your recent deployment activity and CI history.
A good sanity check is to confirm that the backend is reachable and the state is readable:
terraform state pull >/dev/null
If terraform state pull works and no active run exists, the lock is probably stale. If you are not completely sure, coordinate with your team before removing it. Removing a valid lock can cause state corruption.
3. Use terraform force-unlock
Once you have confirmed the lock is stale, terraform force-unlock is the built in way to remove it. It clears the lock using the lock ID shown in the error output. It does not modify your infrastructure.
Use it only after you have verified that no active apply or other state-changing operation is running.
terraform force-unlock LOCK_ID
If you are working with multiple workspaces or directories, run the command from the same folder where the backend configuration matches the locked state. If the backend configuration changed recently, reinitialize first:
terraform init -reconfigure terraform force-unlock LOCK_ID
If you are using a local state, another process cannot unlock it for you.
After unlocking, run a low-risk command such as terraform plan to confirm everything looks consistent before applying changes again.
4. Verify backend health and permissions
Sometimes the error looks like a locking problem, but the real issue is the backend. If Terraform cannot read or write lock data because of missing permissions, misconfigured credentials, outages, or throttling, lock acquisition will fail.
Start with a basic backend check:
terraform init terraform state pull >/dev/null
Then verify the most common backend-specific issues:
- For S3, confirm access to the state object and the lock mechanism you use
- For AzureRM, verify access to the storage account, container, and blob lease operations
- For GCS, verify bucket permissions for object reads and writes
If these checks fail, fix connectivity, IAM, or service health issues first. Re-running Terraform without fixing the backend usually creates more confusion about the actual lock state.
5. Retry the operation
Once you have confirmed there is no active run, cleared any stale lock, and the backend is healthy, a retry is often enough. Lock acquisition can fail because of brief network issues, backend throttling, or other transient problems.
Start with a clean initialization, then retry the command:
terraform init terraform plan
If you keep hitting the same message and you are confident the problem is temporary, increase how long Terraform waits for the lock:
terraform plan -lock-timeout=5m terraform apply -lock-timeout=5m
Use retries as the last step, not the first. If repeated retries fail, go back to the lock details and backend checks. That is usually where the real root cause becomes clear.
Key points
Error acquiring the state lock usually means one of two things: another run is legitimately holding the lock, or a previous run left a stale lock behind.
The fastest safe path is to confirm that no active Terraform job is running, check whether the lock metadata is old, and use terraform force-unlock only when you are sure the lock is stale.
If the error keeps returning, treat it as a backend reliability, permissions, or configuration issue and verify your remote state services before retrying with a sensible -lock-timeout.
If you use Spacelift, troubleshooting is often simpler because you can see which stack run is holding the lock, stop or rerun it cleanly, and avoid risky manual unlocks. You also get centralized visibility, policy-based guardrails, and support for multiple IaC workflows in one place. That positioning aligns with Spacelift’s messaging around governed orchestration rather than ad hoc scripts or manual workarounds.
To learn more, you can create a free account today or book a demo with one of our engineers.
Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. OpenTofu is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.