IO get ERROR_ALREADY_EXISTS with ReFS Block Cloning on SMB share. How can I repair allocation bitmap structures?

Question

IO get ERROR_ALREADY_EXISTS with ReFS Block Cloning on SMB share. How can I repair allocation bitmap structures?

Quinn 20

I've aged 7 years this morning trying to sort a simple problem which for all it compute power Microsoft cant answer. An enterprise backup application relying on ReFS Block Cloning (fast file clone) fails with ERROR_ALREADY_EXISTS when creating Synthetic Full backups on an SMB 3.1.1 share. HOW DO WE AUDIT AND REPAIR ALLOCATION BITMAP STRUCTURES ON THE TARGET REFS VOLUME? All and any suggestions very welcome. Thanks in advance for your help.

0 comments

1 answer

Your answer

Answer 1

Hi @Quinn

I wouldn't start with chkdsk or refsutil salvage. salvage is intended primarily for severely damaged/unmountable ReFS volumes and copies recoverable data elsewhere; it isn't the normal tool for repairing a mounted backup volume's block-clone metadata.

For your scenario, the more relevant Microsoft-supported diagnostic is:

refsutil triage <drive>: /g /v

/g specifically scrubs the ReFS global tables, which is the closest supported operation for checking filesystem metadata structures involved in allocation/reference tracking.

Also check:

fsutil fsinfo refsinfo <drive>:

and review the System event log for ReFS errors. ReFS block cloning relies on filesystem metadata and reference counts for shared logical clusters, so repeated ERROR_ALREADY_EXISTS during clone operations could indicate a metadata issue, but it could also originate from how the backup application is issuing the clone request.

I would therefore:

Stop backup jobs writing to the affected ReFS volume.

Run refsutil triage <drive>: /g /v.

Check the System log for ReFS events around the failed synthetic full.
Confirm the Windows Server build and ReFS version with fsutil fsinfo refsinfo.
Check whether the backup vendor has a documented ReFS block-cloning issue for that application/build.

I would not use undocumented commands to manipulate the allocation bitmap directly. ReFS doesn't expose a supported equivalent of manually rebuilding NTFS allocation structures.

If refsutil triage reports global-table corruption, or the error reproduces across different backup files after the application/vendor side has been ruled out, I'd open a Microsoft support case before attempting more invasive recovery. ReFS is designed to perform online metadata repair where possible, particularly when resilient storage provides an alternate copy.

If you can post the output of:

refsutil triage <drive>: /g /v
fsutil fsinfo refsinfo <drive>:

plus the relevant ReFS event IDs, we should be able to narrow down whether this is actually filesystem corruption or a block-clone/application issue.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.