Inconsistent behaviour of file share mounted volumes to azure container instance RRS feed

  • Question

  • We have a container application that needs persistent storage across restarts. It keeps application logs, application license, application configuration etc in this storage. File share seems to be best choice to maintain such persistent storage. I followed this article to create a storage account and map mount volumes.

    Application is failing to access certain files in mounted location. I have observed following inconsistencies

    A. Failure to access sqlite3 db file. We use sqlite3 db in our application. In this case even though no other application in container is using sqlite db file. It is always reported as busy/locked. Please follow these steps to recreate the issue.

    1. Create a new resource group issue simulation
        az group create -g test-env
    2. Create a new storage account for volume mounts. File shares in this account will be mounted to container
        az storage account create -g test-env --name volumes31416 --sku Standard_LRS
    3. Create a volume
        az storage share create --account-name volumes31416 --name volume0
    4. Get the keys and update them in resource manager file
        az storage account keys list -g test-env --account-name volumes31416
    5. deploy
        az group deployment create -g test-env --template-file deployment.json
    6. Issue Simulation
    case 1, (here we are accessing file that is not mounted with file share and everything goes fine)
    cd /
    touch new.db
    /db_check new.db "create table InfoTable (Name TEXT PRIMARY KEY NOT NULL)"
    case 2(this location is mounted on file share and it breaks)
    cd /root/test_dir
    touch new.db
    /db_check new.db "create table InfoTable (Name TEXT PRIMARY KEY NOT NULL)"
    Failed to step :database is locked

    All relevant files are available in following location, (Dockerfile is copying local content, it may not work). db_check is compiled output of sqlite_check.c

    In case of directories not mounted, sqlite is able to access files as it is intended. It fails in case of file share mounted volumes.

    B. If A file is deleted in storage explorer. The change doesn't get reflected to container for significant duraiton(~10 seconds in some cases). Are such deletions eventually consistent?

    C. We have 2 binaries using same tls code base to process pkcs certificates. However only one of them(say B1) is able to process license and other(say B2) always fails. Please note that both binaries B1 and B2 are running fine if we don't use file share. On other container platform (like docker on VM) application is able to process certificates just fine. B2 gives error as mac verify failure that is incorrect password or corrupted file. I suspect it to be later case but don't have any solid evidence.

    As per above observation, Can you please tell why file access is not consistent. Is it intended way azure file share works or there is any problem with my configuration.

    Thursday, November 14, 2019 1:32 PM

All replies

  • In the doc you linked, I noted a note at the top of the page

    Might that be the issue?

    Thursday, November 14, 2019 6:15 PM
  • Hi Micah, Thanks for your response.

    As per this note content of file share will be visible to application, not the content that would have been there without volume mounting. This is fine and expected to be like that. Problem is that, a file in folder that is mounted behaving differently than a file that is not mounted.

    In the sample docker image I have added there is no file in folder that is mounted on file share, so i think this doesn't apply anyway.

    Thursday, November 14, 2019 7:03 PM
  • Hi Vikash,

    I will reproduce your issue and update you with my findings.

    Monday, November 18, 2019 12:16 PM
  • Hi Vikash, Based on my understanding, the files should remain constant. So not sure what is missing here. 

    I would like to get you in touch with Technical Support to dig into this deeper. If you would like to go down that route, please email me at and provide me with your SubscriptionID and link to this issue. I can then help to get a ticket opened for you. 

    Friday, November 22, 2019 8:50 PM
  • Hello,

    Any update on the issue?

    If the issue is fixed, request you to reply here on this thread with the resolution steps for the benefit of the community.


    Tuesday, November 26, 2019 10:37 AM