Is there a fall-back path? Share/Remotepath not respected

[williamayerst]

Hi guys,

I had this working briefly, but I'm running into issues: it seems no matter what I do, docker is looking for a top level share in my Azure storage account called 'volumes'. This happens to coincide with the first share I created in that storage account for testing - but I cannot find where this setting is being cached - I have removed and re-installed Docker and Docker-Compose, rebooted, cleared all containers (online, offline, etc.) and all volumes.

I thought I would work around this by using remotepath, but it seems to be entirely discarded as noted here: https://github.com/Azure/azurefile-dockervolumedriver/issues/63

I wonder if /volumes is the default share name if there is a parsing or connection issue to specific shares/remotepaths?

I am using Docker Compose to parse the parameters:

version: '2'
services:
  db:
    ...
    volumes:
      - postgresql:/var/lib/postgresql/data
    ...
  jira-container:
    ...
    volumes:
      - jira:/var/atlassian/jira
    ...
volumes:
  postgresql:
    driver: azurefile
    driver_opts:
      share: "volumes"
      remotepath: "postgresql"

  jira:
    driver: azurefile
    driver_opts:
      share: "volumes"
      remotepath: "jira"

[williamayerst]

I have decided to put aside remotepath and work entirely on a share basis:

volumes:
  postgresql:
    driver: azurefile
    driver_opts:
      share: "postgres"

  jira:
    driver: azurefile
    driver_opts:
     share: "jira"

It would appear that one needs to manage the docker volumes to ensure there's nothing hanging around, I couldn't figure out exactly what the issue was, but running the following command docker rm -f $(docker ps -a -q) && docker volume rm $(docker volume ls -q) to wipe all containers, all container volumes and then running a docker-compose up -d got it running,