Using Azure File Shares with Azure File Sync while also pointing a cloud file share product like MyWorkDrive directly at the same Azure File Share creates a multi-writer scenario that Azure File Sync is not designed to handle, leading to file lock conflicts and delayed or conflicting updates. learn.microsoft
Scenario overview
In this pattern, users work on a traditional SMB share on‑premises (backed by Windows Server), that server syncs to Azure File Shares using Azure File Sync, and at the same time remote users connect to the same Azure File Share through MyWorkDrive. That effectively turns Azure Files into a shared “hub” for two separate access paths that are unaware of each other in real time. myworkdrive
Why file locks break down
Azure Files supports SMB locking and REST/HTTP access, but lock coordination only applies to SMB clients attached directly to the Azure File Share, not to separate copies of the namespace on Windows servers synced via Azure File Sync. Azure File Sync does not provide global, cross‑site locking; if one user has a file open on‑prem, another user accessing it via MyWorkDrive in Azure can still open and edit it, generating conflict copies instead of a single authoritative version. learn.microsoft
MyWorkDrive maintains its own file locking for sessions it serves and interoperates with SMB when it fronts a single file server, but it cannot see or respect open handles on a separate on‑premises file server that is merely syncing to Azure Files through Azure File Sync. The result is that neither system has a complete view of who has a file open, so users can overwrite each other’s changes or end up with multiple “filename‑conflict‑copy” versions to reconcile manually. youtube
Example: conflicting edits
- User A opens a document from the on‑prem SMB share and leaves it open while working. myworkdrive
- User B opens the same document via MyWorkDrive from the Azure File Share and saves changes. youtube
- Azure File Sync later pushes/pulls updates between the server and Azure File Share, detects a mismatch, and creates conflict copies because it cannot merge two independent change histories with no shared locking. myworkdrive
Azure File Sync is not real time
Azure File Sync is optimized for caching and tiering, not real‑time collaboration or multi‑master access. It tracks changes on the Windows Server side via the USN journal and can sync those relatively quickly, but changes made directly in the Azure File Share (for example by MyWorkDrive, other SMB clients, or portal operations) are discovered by a scheduled change‑detection job that runs approximately every 24 hours and must enumerate the entire share. reddit
Because Azure Files does not provide change notifications or journaling that Azure File Sync can subscribe to, there is no automatic, instantaneous push of cloud‑side changes back to the on‑premises server. Admins can manually invoke change detection (for example with the Invoke‑AzStorageSyncChangeDetection cmdlet) but that is operational overhead and still not equivalent to continuous, low‑latency replication. learn.microsoft
Impact of non‑real‑time sync
- Users on‑prem may not see changes made via MyWorkDrive in Azure for many hours, leading to users opening stale versions of files. reddit
- When the next sync finally runs, Azure File Sync must reconcile two divergent versions and will often generate conflict copies rather than gracefully merging changes. myworkdrive
- In large namespaces, change detection across the Azure File Share can take longer than 24 hours, further increasing the window where users are working on outdated data. reddit
Recommended patterns instead
Vendors and Microsoft documentation position Azure File Sync for scenarios like branch caching, centralization, and migration, not as a real‑time multi‑site collaboration engine with global locking. For remote access, a better pattern is to choose a single “source of truth” access path per file share: either expose Azure Files directly (for example via MyWorkDrive) without Azure File Sync in front of it, or keep users on the on‑premises file server and use MyWorkDrive against that server, with Azure File Sync used only for DR, backup, or secondary caching where no one writes directly in Azure. myworkdrive