Hi David,
Indeed, it was an issue of rights of writing data to Azure. In particular in the setup of the StorageClass
in Kubernetes, you can set additional mountOptions
. One of those is the uid
which should be set to 100 - the user id used for neo4j.
Example of the StorageClass yaml:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azurefile-neo4j
provisioner: kubernetes.io/azure-file
reclaimPolicy: Retain
mountOptions:
- dir_mode=0755
- file_mode=0755
- uid=100 # Allow write access for neo4j
- gid=1000
parameters:
skuName: Standard_LRS
It is curious though that the file /data/dbms
was written successful before, while /data/databases
could not be written. Seems that dbms and databases are created by different users? But that would be a separate question.