Reflect 8 No Longer Mounts an Image File for Windows Explorer

kelper said:

bobeeire​

OK, that's your choice. But I think you need to trap there missteps or you will alienate potential users. I am creating recovery media on a smaller USB. Then, I will do a system backup and then a restore.

Click to expand...

You're right — it should have checked, and it didn't. That's a straight miss: the builder spent twenty minutes assembling the boot image and then failed on something knowable in the first second.

Fixed. The drive picker will now mark any stick over 32 GB ("TOO LARGE FOR FAT32") and refuse it before the build starts, with the reason spelled out — the media is formatted FAT32 and Windows can't FAT32-format anything above 32 GB. The check will also exist server-side (CLI included), and if a format failure like yours does slip through, the error now explains the size limit instead of just quoting a DiskPart code. For bigger sticks the suggestion is: build the ISO and write it with Rufus, which can format larger FAT32 volumes. This ships in the next release (0.6.93).

And fair on the wider point too — "trap the missteps before users hit them" is the right standard, and I'd rather hear it than lose you as a tester. restoring the system disk from inside Windows is now blocked up front (that's the fix from 0.6.92), and I've also just implemented the nicer version of that story — OPBS can now stage the restore and run it automatically after a one-shot reboot into a recovery environment built from your own Windows RE image, then come back to Windows and report the result. It's in testing now; I'll say more when it's shipped.

SIW2 said:

could add the .wim to the windows boot menu if desired.



Is there a reason it does not use winre.wim as the base ? winre.wim can be copied then the program and winpeshl.ini shoved in using something like wimlib

I have made simple boot media that way without bothering to mount the copied winre.wim.

I usually put a little menu in so the one wim can accomodate several programs

Click to expand...

Both good points — and no, there was no strong reason against winre.wim. It's now the base for the flow I am adding, your exact pattern. The machine's winre.wim gets copied (never modified in place), the OPBS payload and a staged restore config sit beside it, and a launcher is injected so the restore runs automatically and the machine reboots back to Windows afterwards. No ADK involved at all — system DISM does the injection — which also sidesteps the ADK install failures kelper has been fighting.

On the boot menu: rather than adding it to the visible menu, the entry is set as a one-shot bootsequence, so it fires only on the next restart and the normal menu is never changed. And per your tenforums guide (small world), the ramdisk device is a dedicated /create … /device object — the shared {ramdiskoptions} that WinRE uses is left strictly alone, so the machine's recovery environment keeps working exactly as before. There's a 10-second cancel window at boot before anything is written, and a result marker comes back to Windows for OPBS to report.

The wimlib no-mount trick is neat — worth a look if the DISM mount ever becomes the slow part. Thanks for the pointers.

kelper said:

I booted from the new usb and tried to restore. More errors.

Validating the plan (preflight — nothing is written)...
[2026-10-28T04:56:46.872Z] [INFO] Restore chain resolved: E:\opbs-disk0-2026-10-27T17-58-12.opbs

Image: E:\opbs-disk0-2026-10-27T17-58-12.opbs
Verify before write: no
Target partitions: disk 0 part 0 @1.0 MB, disk 0 part 1 @301.0 MB, disk 0 part 2 @317.0 MB, disk 0 part 3 @130.4 GB
Partition table: keep existing (no layout change)

Type RESTORE to start the restore, anything else to cancel.
Confirm > RESTORE

Starting restore — do not power off this machine.
[2026-10-28T04:56:53.654Z] [INFO] Restore chain resolved: E:\opbs-disk0-2026-10-27T17-58-12.opbs
[writing] 0% 316 MB/132 GB 124 MB/s Partition 2 clearing free space
Restore FAILED: Write failed for Partition 2 block 0 at 332398592: WriteFile failed on \\.\PhysicalDrive0 at offset 332398592 (1048576 bytes): Access is denied. (error 5 / 0x5)

The wizard ended with code 1.
Press any key to continue . . .

Click to expand...

First, the good news, because the log looks alarming: your Windows partition was not touched. The failure is at the very first block write to Partition 2 (the Windows volume) — the restore refused that write, so nothing on C: was overwritten. The two small partitions before it (EFI and MSR) were rewritten from your own image, which is the same content that was already there. Try booting the machine normally first — Windows should come up as usual.

What went wrong is our bug, and a bad one: the recovery environment still had the Windows volume mounted when the restore started. OPBS tries to dismount target volumes before writing — that step failed quietly, warned internally, and the restore pressed on anyway and hit "Access is denied" at the first write. It should have stopped right there before writing anything, and now it does: the restore refuses to start (nothing written) when a target volume can't be locked, and the error message now says exactly what the cause is instead of a raw system code.

One thing in your log worth explaining while I'm here: the "132 GB" total — that's the "clear free space after restore" option (it zeroes every block the backup didn't contain, so nothing created after the backup can be recovered). It's a security feature and it was on by default without saying so, which also made the restore look far bigger than your image. The wizard now shows it and lets you choose.

To pin down the exact cause of the lock on your machine: is C: BitLocker-encrypted? In Windows, run manage-bde -status C: in an admin command prompt. If it says "Protection On", the recovery environment sees a locked volume and the restore has to unlock (or suspend BitLocker for one boot) before writing — tell me and I'll give you the exact steps for the USB you have now. If it says "Protection Off", then it was the mounted/held-volume case above, and the fix covers it.

Either way: boot normally and confirm Windows is intact first — then we get your restore done.

So does restore work with Ver 8 paid

man00 said:

So does restore work with Ver 8 paid

Click to expand...

Yes — restore (and Browse Files) accepts Macrium Reflect 7/8 .mrimg containers regardless of edition. The paid versions write the same container format as the Free one, and OPBS restores full, differential and incremental chains from it. Reflect X (.mrimgx) is supported too.

One important exception: if your images were created with Reflect's encryption/password protection (a paid-edition feature), OPBS can't open them yet — encrypted Macrium images are on the roadmap, and I'll say more here when that lands. If your images have no password, you're good to go. A gentle first step either way: open the image in Browse Files — it's read-only, so you can confirm OPBS sees the partitions and files before committing to a restore.

Could OPBS write a small FAT32 partition and make the rest NTFS? A 32GB USB stick won't hold my Windows OS. You accept all our criticisms with good grace - thanks.

And, to answer your question, I never use Bitlocker.

I'm now trying with a 120 GB USB SSD. I made two partitions, one FAT32 partition of 1GB and the second partition NTFS of about 118GB for backups.

But still it failed, pehaps because it did not check thesize of the partition?

Image File : C:\Users\Martin\AppData\Local\Temp\opbs-winpe-WfDDmo\build\media\sources\boot.wim
Image Index : 1
Saving image
[==========================100.0%==========================]
Unmounting image
[==========================100.0%==========================]
The operation completed successfully.
Formatting E:...

ERROR: Failed to format "E:"; DiskPart errorlevel -2147024809.
**********************
Windows PowerShell transcript end
End time: 20261028090246
**********************