You type configure and get back:

error: configuration database locked by:
  user Terminal (pid 22210) on since 2026-09-20 08:14:31 UTC
      exclusive

This is one of the most-asked questions on the Juniper support portal and r/Juniper, and the fix is usually thirty seconds — as long as you know where the lock lives and what not to do.

Why Junos Locks the Configuration

Unlike IOS, where two admins can type conflicting commands at once, Junos gives every session a candidate configuration. A lock guarantees that only one candidate can be committed at a time, preventing two engineers from silently overwriting each other. The lock is held by a username and process ID, shown directly in the error message — that PID is your starting point.

Step 1: Find Who Holds It

show system users
show system processes | match mgd

show system users lists every active login with idle time. Nine times out of ten the lock belongs to a colleague's idle SSH session — or your own second terminal window you forgot about. From configuration mode, status shows exactly who holds the current database and whether it is exclusive.

Step 2: Clear It Politely

If the holder is idle, log the session out cleanly:

request system logout pid 22210

That kills the session, releases the lock, and any uncommitted candidate changes are discarded safely. Then enter configuration mode normally. If the lock is your own forgotten session, simply find that terminal and type exit.

Step 3: Stale Locks from Dead Sessions

Sometimes the PID in the error belongs to nothing — a session that died during a network outage. After confirming with show system users that no live user matches, request system logout pid still clears the leftover lock. If even that fails, the last-resort fix is restarting the management daemon:

request system logout pid 22210
restart mgd gracefully

Warning: restarting mgd drops all management sessions (SSH, NETCONF, J-Web). On a chassis cluster it can trigger failover. This is a maintenance-window action, not a reflex.

Exclusive vs Private Mode — Prevent the Problem

  • configure exclusive — grabs the lock immediately; nobody else can configure until you commit or quit. Best for risky changes where nobody else must touch the box.
  • configure private — gives you your own candidate; multiple engineers can configure simultaneously, but commits race and later committers may see their changes invalidated.

Default (shared) mode plus good communication is fine for most teams; use exclusive for cut-overs.

Chassis Cluster Trap

On SRX chassis clusters, the lock is per-node. If someone committed on node0 and you are troubleshooting on node1, you may see a lock that looks unexplainable. Always run show chassis cluster status first, and work on the node that actually holds the lock.

If you are new to the Junos commit model itself, start with the Junos CLI crash course; if you are locked out of the box entirely rather than just the config, follow the root password recovery procedure; and if a stuck lock appears during a software upgrade, the upgrade validation troubleshooting guide covers that scenario end to end.