Failed to write attributes for file

[dhcgn]

Hello,

I want to use AzureFile with (Bittorent) Sync, but the container crashes after a few seconds. (It works without the volume mapping)

It seems, that there is a problem with file attributes, is this a limitation of azure files?

Docker

docker run -d \
  -v $(docker volume create -d azurefile  -o share=btsync):/mount/data       \
  -p 3369/udp -p 3369                            \
  -e BTSYNC_NAME='btsync-docker-server'              \
  -e BTSYNC_SECRET_XYZXYZXYZXYZXYZXYZXYZXYZXYZXYZXYZ=Data_1 \
  -e BTSYNC_SECRET_XYZXYZXYZXYZXYZXYZXYZXYZXYZXYZXYZ=Data_2 \
  grahamc/btsync

Log

SyncFileEntry: Failed to write attributes for file /mount/data/XYZ/XYZ - 1
(A very large amount of the same error with other paths)

assert failed ./SyncFilesControllerRO.cpp:365 (16973930)
/opt/btsync/start: line 8: 15 Aborted (core dumped) /opt/btsync/btsync --nodaemon --config /mount/config/0conf.conf

[ahmetb]

It appears to be a limitation with the azure files or some kind of OS/cifs bug.

Could you try creating and mounting azure file storage volumes manually and see if it keeps happening as well? https://azure.microsoft.com/en-us/documentation/articles/storage-how-to-use-files-linux/

[njappboy]

@ahmetalpbalkan I'm having a similar issue that seems to stem from a directory permission issue with the volume.

I'm trying to deploy a postgresql container via docker-machine to Azure with a volume mounted for the PG_DATA location.

I'm using the official postgres:latest image from docker hub.

I deployed the docker-machine to azure using the docker-machine azure driver -d azure. No issue there, working correctly.

After deploying docker-machine I use docker-machine ssh mytarget-machine to connect to the machine. Once remoted in I clone this repository, build the driver, and install it via systemd using this script.

My docker-machine host is Linux mytarget-machine 4.2.0-38-generic #45-Ubuntu SMP Wed Jun 8 21:21:49 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux, hence systemd usage.

Next I pull the image:

$ docker pull postgres

Create the volume:

$ docker volume create --name postgres-data -d azurefile -o share=postgresgitdata

Run the container:

$ docker run --name postgres1 -e POSTGRES_PASSWORD=password -e POSTGRES_USER=admin -e POSTGRES_DB=gogs -e PGDATA=/var/lib/postgresql/data -v postgres-data:/var/lib/postgresql/data -p 5432:5432 -d postgres

The container starts and then exits almost immediately. Here is the container log:

$docker logs postgres1
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

initdb: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted
fixing permissions on existing directory /var/lib/postgresql/data ...

If I run docker inspect postgres1 the mount looks correct:

"Mounts": [
            {
                "Name": "postgres-data",
                "Source": "/var/run/docker/volumedriver/azurefile/postgres-data",
                "Destination": "/var/lib/postgresql/data",
                "Driver": "azurefile",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            }
        ]

Is the empty Mode property above related to directory permissions? Is it missing a value? When I look at the manual mounting of a file share I see the sudo mount -t cifs operation pass dir_mode=0777 as part of its arguments. Does this value directly translate to the Mode property we see above when manually mounting? <- Pure speculation on my part.

Any thoughts or additional information I could provide?

Should I too attempt to manually mount and see if the problem persists?

[njappboy]

@ahmetalpbalkan Corrected: I am seeing the same issue if I create the azurefile volume, mount on the host, and then start/stop container. Seems to be a cifs issue.

Steps:

$ # Create volume - share name 'sdata'
$ docker volume create --name sample-data -d azurefile -o share=sdata

$ # ssh to host
$ sudo mkdir -p /mnt/mymountpoint
$ sudo mount -t cifs //vhds7rby6hwg7u2kto666vx7.file.core.windows.net/sdata /mnt/mymountpoint -o vers=3.0,username=vhds7rby6hwg7u2kto666vx7,password=somemadeuppassword==,dir_mode=0777,file_mode=0777

$ # Start container
$ docker run --name postgres1 -e POSTGRES_PASSWORD=password -e POSTGRES_USER=admin -e POSTGRES_DB=gogs -e PGDATA=/var/lib/postgresql/data/pgdata -v //vhds7rby6hwg7u2kto666vx7.file.core.windows.net/sdata:/var/lib/postgresql/data -p 5432:5432 -d postgres

[ahmetb]

@njappboy also you probably should not be running a postgres db on Azure File Storage. It's not particularly a recommended use case.

[njappboy]

@ahmetalpbalkan I'm performing due diligence on the platform to determine usability. I agree that postgres on Azure File Storage is not a good use case. There currently isn't any other option I'm aware of on the Azure platform, until there are more volume drivers available that work consistently well or until a block io solution comes to the platform. If you have timelines for new drivers or block io please share them. I tried using GlusterFS for persistence as well with limited success. In your opinion should SMB just be avoided until the Nix distros catch-up with their SMB 3.0 implementations? Is GlusterFS worth pursuing?

In this particular case I'm trying to back a gogs container with postgres. I originally configured gogs to use sqllite and persist to a docker volume but ran into similar file locking issues, hence I tried using the volume with postgres to see if the issue was gogs specific or azure docker volume specific.

[ahmetb]

@njappboy I don't have any timelines, however I think we have a service coming up that would allow users to create and mount block devices via the API (just like data disks we have today, but more programmable).

[edevil]

Will that require a different docker volume driver? I'm also interested in persistent docker volumes in Azure that can be used for DB persistence.

[ahmetb]

@edevil We currently have no volume drivers on Azure that would let you smoothly and safely run a database unfortunately. I have provided a bit of detail in my comments above. Essentially, creating a durable and robust container persistence solution would require block devices support and the current offerings are not meeting the demands. However there is work going on to fix this gap.

[ahmetb]

Closing as it is not directly related to the currently supported features of driver.