Permission errors with cloudstor and Azure file storage

General
1

I have an issue with my volume using an Azure file storage and the cloudstor driver in a swarm cluster.

Expected behavior

Use my azure file storage as a volume in order to externalize my volumes data and give needed permissions to my containers using volumes.

Actual behavior

I’m using several volumes with a Redis and a postgres containers as you can see on this part of my docker-compose.yml

db:
    image: postgres:9.6
    volumes:
        - db_data:/var/lib/postgresql/data

redis:
    image: bitnami/redis:latest
    volumes:
        - redis_api_data:/bitnami

volumes:
    redis_api_data:
        driver: cloudstor:azure
        driver_opts:
            share: redis-api-data

    db_data:
        driver: cloudstor:azure
        driver_opts:
            share: db-data

When I deploy my stack for the first time, volumes are created, I can see them with
docker volume ls and if I go inside my storage in the azure portal I can see that volumes was created too.

So far, so good, but when I explore inside the postgres volume from the azure Portal, there is no folder or file in it.
And if I check the container logs, I can see the following message :

initdb : could not change permissions of directory “var/lib/postgresql/data”: Operation not permitted

It seems that I have a permission issue between my postgres container and my volume on Azure.

It’s strange because with the redis one, I can see that data were correctly wrote in my volume. But I have also a permission issue when I restart the service and when it try to restore data, I can see the following message

Error executing ‘postInstallation’: EPERM: operation not permitted, utime ‘/bitnami/redis/.restored’

Additional Information

  • Output of docker version

    Client:
    Version: 18.02.0-ce
    API version: 1.36
    Go version: go1.9.3
    Git commit: fc4de44
    Built: Wed Feb 7 21:16:33 2018
    OS/Arch: linux/amd64
    Experimental: false
    Orchestrator: swarm

    Server:
    Engine:
    Version: 18.02.0-ce
    API version: 1.36 (minimum version 1.12)
    Go version: go1.9.3
    Git commit: fc4de44
    Built: Wed Feb 7 21:15:05 2018
    OS/Arch: linux/amd64
    Experimental: false

    • Output of docker info

    Containers: 0
    Running: 0
    Paused: 0
    Stopped: 0
    Images: 1
    Server Version: 18.02.0-ce
    Storage Driver: overlay2
    Backing Filesystem: extfs
    Supports d_type: true
    Native Overlay Diff: true
    Logging Driver: json-file
    Cgroup Driver: cgroupfs
    Plugins:
    Volume: local
    Network: bridge host macvlan null overlay
    Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
    Swarm: active
    NodeID: x8vgzlyyw6068b7frxz6a1qyf
    Is Manager: true
    ClusterID: iwyz30ns16a7ixamoh0gzpky3
    Managers: 1
    Nodes: 3
    Orchestration:
    Task History Retention Limit: 5
    Raft:
    Snapshot Interval: 10000
    Number of Old Snapshots to Retain: 0
    Heartbeat Tick: 1
    Election Tick: 3
    Dispatcher:
    Heartbeat Period: 5 seconds
    CA Configuration:
    Expiry Duration: 3 months
    Force Rotate: 0
    Autolock Managers: false
    Root Rotation In Progress: false
    Node Address: 172.16.0.5
    Manager Addresses:
    172.16.0.5:2377
    Runtimes: runc
    Default Runtime: runc
    Init Binary: docker-init
    containerd version: 9b55aab90508bd389d7654c4baf173a981477d55
    runc version: 9f9c96235cc97674e935002fc3d78361b696a69e
    init version: 949e6fa
    Security Options:
    apparmor
    seccomp
    Profile: default
    Kernel Version: 4.4.0-66-generic
    Operating System: Ubuntu 16.04.2 LTS
    OSType: linux
    Architecture: x86_64
    CPUs: 1
    Total Memory: 658.4MiB
    Name: swarmm-master-13957614-0
    ID: HERQ:UJO5:ZWFU:HNXY:6HP6:EM4M:5JSD:2FK4:VTBY:PE4X:WMDV:WHNB
    Docker Root Dir: /var/lib/docker
    Debug Mode (client): false
    Debug Mode (server): false
    Registry: https://index.docker.io/v1/
    Labels:
    Experimental: false
    Insecure Registries:
    127.0.0.0/8
    Live Restore Enabled: false

  • Output of docker-compose version

    docker-compose version 1.12.0, build b31ff33
    docker-py version: 2.2.1
    CPython version: 2.7.13
    OpenSSL version: OpenSSL 1.0.1t 3 May 2016

Steps to reproduce the behavior

I created my swarm cluster with this azure template :

https://github.com/Azure/azure-quickstart-templates/tree/master/101-acsengine-swarmmode

I installed cloudstor on every node of my cluster with the following command :

docker plugin install docker4x/cloudstor:18.02.0-ce-azure1 --alias cloudstor:azure --grant-all-permissions CLOUD_PLATFORM=AZURE AZURE_STORAGE_ACCOUNT_KEY="<storage_key>" AZURE_STORAGE_ACCOUNT="<storage_account>"

Finlly I deployed my stack on my swarm cluster.

Does anyone know what is the issue ?