423 Locked: Trace the Lock and Release It

Problem

You send a request — a save, a PUT, a MOVE, an API write — and back comes 423 Locked. Nothing is wrong with what you sent. The resource itself is off-limits: something has placed a lock on it, and the server refuses to let a second writer touch it until that lock is gone. This isn’t a state conflict or a permission problem. It’s a reservation. Somebody, or some process, is holding the resource, and the server is protecting whoever holds it from being overwritten. Your job is to find out who holds the lock — and whether that’s you.

Symptoms

• The response status is 423 Locked. In WebDAV, the body is XML carrying a precondition element such as <DAV:lock-token-submitted> or <DAV:no-conflicting-lock>.
• In SharePoint, OneDrive, or Office, the human-facing version reads “This file is locked for editing” or “locked for shared use by .”
• The same write succeeds once the lock clears — closing the document, ending the session, or waiting out a timeout makes the error disappear on its own.
• A browser typing the URL never sees a 423; browsers treat it as a generic 400. If you’re looking at a real 423, you’re using a WebDAV client, an API, or reading server logs.

What This Error Actually Means

423 was defined in RFC 4918 §11.3, the WebDAV specification: “the source or destination resource of a method is locked.” WebDAV added the ability to LOCK a resource before editing it so two authors editing the same file over HTTP couldn’t silently clobber each other — the “lost update problem.” When you take a lock, the server hands you a lock token. To make a change while the lock is held, you present that token back in the If request header. No token, or the wrong one, and the write is refused with 423 and a DAV:lock-token-submitted precondition. A conflicting depth-infinity LOCK over a collection that already contains a locked member fails the same way, with DAV:no-conflicting-lock.

Plain web servers don’t lock resources on their own, so most 423s today come from two places. The first is the WebDAV world it was designed for — SharePoint, OneDrive, Nextcloud, and any Office-over-WebDAV setup, where a file open in a desktop application is locked against edits until the app closes. The second is modern APIs that borrowed 423 as a general “this resource is reserved” signal: a record checked out by a workflow, a document held by an editing session, a job that locked its own row while running, an account frozen mid-operation. Same meaning in both: the resource is spoken for, and the fix is to release the reservation, not to retry harder.

Top 3 Causes

1. A file is open in a desktop app (SharePoint / Office / OneDrive) - The overwhelmingly common cause outside pure WebDAV. Someone has the document open in Word, Excel, or a synced client, which holds an editing lock. Until that app closes — and the post-close grace period elapses — every other write gets 423. If the app crashed, the lock is stale and outlives the person who set it.
2. You didn’t submit the lock token you’re supposed to hold - You (or your client) LOCKed the resource but the follow-up write omitted the token, or sent a stale one, in the If header. The server can’t tell your write apart from an intruder’s, so it refuses with DAV:lock-token-submitted. This is a client-side bug: acquire the lock, then thread its token through every subsequent request.
3. An application-level lock the API sets on purpose - The endpoint deliberately locks the resource during a workflow — a document checked out for editing, a booking held during checkout, a job that reserves its record while it runs, a temporarily frozen account. The 423 is working as designed; you clear it by finishing or cancelling the operation that took the lock, or by waiting for its timeout.

Diagnose with DechoNet

• HTTP Check confirms the endpoint really returns 423 and captures the response headers and body — which, for a well-behaved WebDAV or API server, is where the lock owner, the precondition element, or a Retry-After hint lives. That body is the difference between “wait it out” and “submit a token.”
• It also confirms the 423 comes from the origin rather than a proxy or gateway that rewrote something else into it, so you’re chasing the layer that actually holds the lock. If the failing endpoint is a hostname that won’t resolve at all, DNS Check rules out a plain reachability problem masquerading as an application error.

Resolution Checklist

• Read the response body, not just the status. WebDAV names the problem: lock-token-submitted means you need to present a token; no-conflicting-lock means an existing lock is in your way. An API often names the owner or the operation holding the resource.
• If it’s your lock, submit the token. Put the active lock token in the If header on the write, or re-LOCK if the token expired. If your client acquired a lock and never released it, UNLOCK it.
• If a desktop app holds it, close the app fully on every machine that had the file open, then wait out the grace period. In SharePoint/OneDrive, check the file’s “locked by” detail — a synced client on a machine nobody’s watching is the classic culprit.
• If the lock is stale — the holder is gone but the lock survives — don’t retry blindly. Wait for the timeout, or have an admin/owner force-release it (SharePoint’s “check in” / discard checkout, an UNLOCK with the token, or the API’s admin unlock).
• Confirm you’re not confusing 423 with its neighbors: no lock but a state clash is 409, a failed If-Match is 412, a required-but-missing precondition is 428, and a cascade from another failure is 424. The fix for each is different.

When to Escalate

• If the resource stays locked with no identifiable owner and no timeout in sight, it’s a stale lock the system won’t reap on its own. That’s an operator action — force-release or lock cleanup — not something a caller can fix by retrying.
• If 423s appear under concurrency (many writers hitting the same resource at once), the lock is doing its job but your workflow is serializing on a hot resource. That’s a design problem — shorten lock hold times, narrow lock scope, or queue writers — not a bug in any single request.
• If you own the API returning 423, make sure the response body says who holds the lock and when it expires. A bare 423 with no owner and no Retry-After turns a self-service wait into a support ticket.