locked
Azure File Sync - Not sync'ing RRS feed

  • Question

  • I have 2 Azure File Shares that I am trying to sync with an Azure VM.

    One share sync's correctly, the other has not been able to sync anything.

    Configuration:

    2 Sync Groups

        Health: Green check

        Region: Southeast Asia

        Music

            Cloud Endpoint

                Azure File Share: "music"

                Provisioning State: "Provisioned"

                Resource Group: "Home"

            Server Endpoint

                Server: "HomeFilesAFS"

                Health: Green Check

                Sync: <blank>

                Path: "S:\Music"

                Cloud Tiering: "Enabled"

                Last Status: 6:26 (30 minutes ago)

        Pictures

            Cloud Endpoint

                Azure File Share: "pictures"

                Provisioning State: "Provisioned"

                Resource Group: "Home"

            Server Endpoint

                Server: "HomeFilesAFS"

                Health: Green Check

                Sync: <blank>

                Path: "S:\Pictures"

                Cloud Tiering: <blank>

                Last Status: 6:26 (30 minutes ago)

    1. The Pictures endpoint successfully sync'd, it contains ~190GB, changes made on server or cloud endpoint propagate correctly
    2. The Music endpoint has not sync'd, not a single file has sync'd
    3. The Music share has 3-4K files, ~30GB
    4. The server HomeFilesAFS is an Azure VM, in Southeast Asia, in the Home resource group, running Windows Server 2016 - Enterprise
    5. S: drive is a Managed Disk: Premium_LRS, no encryption, no host caching
    6. Initially I set Music to not be Cloud Tiering, but changed it just to see if anything would happen
    7. On initial sync, Pictures ran out of space, I increased the size of the disk and it continued to success
    8. The event log on the server is showing no obvious errors.
    9. Obvious things like rebooting did not help

    Is there something wrong with my configuration?

    Why would one endpoint sync and not the other?

    Other diagnostics that can be run?

    Tuesday, October 17, 2017 11:25 AM

Answers

  • The problem has been solved.

    The cause is that it is possible to create file or folder names that have "invalid" characters in them. This caused the initial sync to fail.

    These types of file names cannot be created (nor accessed nor renamed nor deleted) through the REST API (Portal or Storage Explorer). However they can be created (and renamed) through an SMB connection on Windows.

    Solution, mount file share on Windows via SMB, walk through the entire hierarchy looking for names that are unusual (in my case it was the character \u0081), rename them, then sync will succeed.

    Big thank you to Jeff and the product group who tracked this down!

    • Edited by darobins Sunday, October 22, 2017 5:29 AM
    • Marked as answer by darobins Sunday, October 22, 2017 5:29 AM
    Sunday, October 22, 2017 5:28 AM

All replies

  • A thing found in the event logs:

    Event 4035: 0x80c8300f - The replica is not ready to perform the required operation

    Correlation Id {B1D4D562-AF7F-428B-972E-8A31D8128C4B}

    Tuesday, October 17, 2017 11:50 AM
  • Another fact: I have waited multiple days to see if a sync would get scheduled
    Tuesday, October 17, 2017 11:57 AM
  • For a deeper analysis of this issue, I would suggest you open a support ticket as described in this link How to create an Azure support request. The ticket will help you work closely with the support for speedy resolution.

    ------------------------------------------------------------------------------------------

    Do click on "Mark as Answer" on the post that helps you, this can be beneficial to other community members.


    Tuesday, October 17, 2017 5:09 PM
  • Darobins,

    To determine why the files are not syncing to the Azure File share, please run AFSDiag on the HomeFilesAFS sever (instructions are in the troubleshooting guide). Please send the output file (.zip file) to jeffpatt at microsoft dot com.

    Thanks,

    Jeff

    Tuesday, October 17, 2017 11:22 PM
  • The problem has been solved.

    The cause is that it is possible to create file or folder names that have "invalid" characters in them. This caused the initial sync to fail.

    These types of file names cannot be created (nor accessed nor renamed nor deleted) through the REST API (Portal or Storage Explorer). However they can be created (and renamed) through an SMB connection on Windows.

    Solution, mount file share on Windows via SMB, walk through the entire hierarchy looking for names that are unusual (in my case it was the character \u0081), rename them, then sync will succeed.

    Big thank you to Jeff and the product group who tracked this down!

    • Edited by darobins Sunday, October 22, 2017 5:29 AM
    • Marked as answer by darobins Sunday, October 22, 2017 5:29 AM
    Sunday, October 22, 2017 5:28 AM