Thanks for the extra checks — especially the fsutil output, which changed the diagnosis. My earlier explanation was wrong: your volume says Is ReadWrite and NOT Dirty, so it wasn't mounted read-only, and that Access is denied on delete was just Windows permissions on a protected file. Sorry for the misleading theory.And some other checks I did whilst in your PE.
F:\OPBS>mountvol c: /l
\\?\Volume{c33d64ca-495d-4e5a-8d0a-5aeebfa59c61}\
F:\OPBS>fsutil fsinfo volumeinfo c:
Volume Name : Real
Volume Serial Number : 0xb2de32f5
Max Component Length : 255
File System Name : NTFS
Is ReadWrite
Not Thinly-Provisioned
Supports Case-sensitive filenames
Preserves Case of filenames
Supports Unicode in filenames
Preserves & Enforces ACL's
Supports file-based Compression
Supports Disk Quotas
Supports Sparse files
Supports Reparse Points
Returns Handle Close Result Information
Supports POSIX-style Unlink and Rename
Supports Bypass IO
Supports Case-Sensitive Directories
Supports Object Identifiers
Supports Encrypted File System
Supports Named Streams
Supports Transactions
Supports Hard Links
Supports Extended Attributes
Supports Open By FileID
Supports USN Journal
F:\OPBS>fsutil dirty query c:
Volume - c: is NOT Dirty
But your log shows a real bug of ours — the "Image file does not exist" one. The staged restore writes down where the image is as a drive-letter path (in your case E:\opbs-disk0-2026-10-29T19-54-20.opbs). When the machine boots into the recovery environment, letters get re-assigned — exactly what you spotted: the E: there is the volume Windows calls G:, and the file it wants is on yet another volume. So the auto-restore looks in the wrong place and stops. That's on us; the recovery environment can't be trusted to keep drive letters, and we recorded one anyway.
The fix: the staged restore now records where the image lives on its volume (path + file size), and if the old path is gone it finds that exact file on whichever letter the volume has now. It only accepts a size-matched copy, and it refuses to guess if two volumes hold identical copies. When it relocates the image it says so: note: image moved to F:\... (the recorded E:\... is gone — drive letters changed).
To finish your restore now, before the fixed build: use the wizard instead of the auto-restore — it finds images by scanning drives rather than by letter:
X:\OPBS\node.exe X:\OPBS\winpe-entry.js wizard
Pick the image from the list (it'll appear under whatever letter that volume has today), whole disk, same as you did before. When the next build is out, re-staging the restore from the Restore page picks up the fix — both the config and the rescue payload are regenerated then.
About yesterday's "Cannot lock Partition 2": thanks to your fsutil output I can rule out the read-only idea I had — something in that session was holding the volume open instead. Two changes cover it: the restore now waits longer for a busy volume and falls back to forcing the filesystem off it, and it closes the image files it keeps open itself. If it ever happens again, the error now prints the volume's GUID — that one line will settle it.
My Computer
At a glance
w11
- OS
- w11




