Azure Storage Sync not replicate mount point

Yep - unfortunately Azure File Sync does not synchronize through an NTFS mount point/reparse point as though the mounted volume were a normal subfolder. If your file server has something like D:\Shares\Data with D:\Shares\Data\Archive being an NTFS mount point that actually points to another volume, Storage Sync will not traverse that mount point and synchronize the contents of the mounted volume into the corresponding Azure file share folder. That is why you see the parent folder structure in Azure Files but not the data residing behind the mount point.

One approach is to create a separate Server Endpoint for the mounted volume, provided the mounted volume has its own appropriate folder path. For example, if D:\Shares\Data\Archive is a mount point for another volume, you could potentially create a Server Endpoint for the mounted volume itself, such as a directory on that volume, and map that endpoint to a separate Azure file share or an appropriate location. However, you cannot use Storage Sync to make the mounted volume transparently appear as a normal subfolder of the parent Server Endpoint.

If your requirement is specifically to have the mounted volume's contents appear under \\storageaccount.file.core.windows.net\share\Data\Archive, then indeed Robocopy is a reasonable alternative. You can run Robocopy directly against the mounted path, for example robocopy "D:\Shares\Data\Archive" "\\storageaccount.file.core.windows.net\share\Data\Archive" /E /COPYALL /DCOPY:DAT /R:3 /W:5, assuming the Azure file share is accessible and the necessary SMB authentication and permissions are configured.

Note that if this is intended to be an ongoing synchronization rather than a one-time migration, Robocopy can be scheduled to run periodically, but it does not provide the same cloud tiering, change tracking, namespace management, and continuous synchronization capabilities that Azure File Sync provides.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin