Bottom Line: The Failure Pattern Matches Same-Server SMB Copy Offload, Not a Missing File
The copy starts, reaches almost 100%, then Explorer retries and reports that the item can no longer be found. Meanwhile, moving the same data inside ZimaOS Files works. That combination points to the SMB transfer path between two shares on the same serverโnot to the source file disappearing.
Why Windows Treats Same-Server SMB Copies Differently
Windows can request a server-side copy when source and destination are on the same SMB server. Microsoft documents this mechanism as FSCTL_SRV_COPYCHUNK. If that path is not handled correctly, Explorer can fail even though normal read/write access to each share works.
Use a Transfer Path That Does Not Depend on Explorer's Same-Server Optimization
Three practical options:
- Move/copy the files in the ZimaOS Files app.
- Copy Share A to the PC, then from the PC to Share B.
- Use
robocopyand verify the destination.
Microsoft documents retry and copy behavior in the robocopy reference.
Do Not Jump Straight to Permissions
If you can create, edit and delete files independently on both shares, basic credentials are probably not the first failure point. The current ZimaOS SMB help document is the right reference when one share is read-only or credentials are wrong.
What We Can and Cannot Claim
The community case strongly matches a server-side copy compatibility problem, but the current public ZimaOS manual does not document cross-share COPYCHUNK behavior as a supported guarantee. Treat the pattern as a diagnostic shortcut, not a permanent platform label.
For normal sharing setup, see the NAS 101 file-sharing guide and the authenticated ZimaOS SMB example.
