How to solve AzureFile mount error(22): Invalid argument inside container? - kubernetes

Question

I've got an error on mounting AzureFile Share inside AKS(1.18.2) container (build on top of Ubuntu 18.04 with cifs-utils installed):
Warning FailedMount 0s kubelet, aks-nodepool1-37397744-vmss000001 MountVolume.SetUp failed for volume "myapplication-logs" : mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/5e19e1d0-0bfd-4760-a87a-00cb0f3e573a/volumes/kubernetes.io~azure-file/crawler-logs --scope -- mount -t cifs -o file_mode=0777,dir_mode=0777,vers=3.0,<masked> //myazurestorage.file.core.windows.net/crawler-logs /var/lib/kubelet/pods/5e19e1d0-0bfd-4760-a87a-00cb0f3e573a/volumes/kubernetes.io~azure-file/myapplication-logs
Output: Running scope as unit run-r403b463e326d4562a7e44dc8fe018b4b.scope.
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Here is my yaml config:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: myapplication-logs
provisioner: kubernetes.io/azure-file
reclaimPolicy: Retain
allowVolumeExpansion: true
parameters:
skuName: Standard_LRS
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: myapplication-logs
spec:
capacity:
storage: 3Gi
accessModes:
- ReadWriteMany
storageClassName: myapplication-logs
azureFile:
secretName: azurefilesharesecretname}
shareName: myapplication-logs
readOnly: false
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myapplication-logs
spec:
accessModes:
- ReadWriteMany
storageClassName: myapplication-logs
resources:
requests:
storage: 3Gi
---
apiVersion: apps/v1
spec:
selector:
matchLabels:
app: myapplication
replicas: 1
template:
spec:
containers:
name: myapplication
readinessProbe:
httpGet:
path: /probes/ready
port: 5000
timeoutSeconds: 60
periodSeconds: 10
ports:
- containerPort: 21602
- containerPort: 5000
livenessProbe:
httpGet:
path: /probes/healthy
port: 5000
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 30
image: myappacr.azurecr.io/myapplication:1.0.391
volumeMounts:
- readOnly: true
name: secrets-volume
mountPath: /usr/bin/myapp/Secrets
- name: configuration-volume
mountPath: /usr/bin/myapp/Configuration
- name: myapplication-logs
mountPath: /usr/bin/myapp/logs
imagePullSecrets:
- name: acr-dev-regcred
volumes:
- name: secrets-volume
secret:
secretName: myapplication-secrets
- configMap:
name: myapplication-configuration
name: configuration-volume
- name: myapplication-logs
persistentVolumeClaim:
claimName: myapplication-logs
metadata:
labels:
app: myapplication
kind: Deployment
metadata:
name: myapplication-deployment
labels:
app: myapplication
StorageClass, PersistentVolume and PersistentVolumeClaim is successfully deployd without any errors\events.
Cannot find out where is the problem?
Any ideas on what is happening?

Answer 1

There are two ways to consume azure file share as volume from a container in AKS
Manually create and use a volume with Azure Files share. Docs here
In this case the PV need to specify mountOptions
apiVersion: v1
kind: PersistentVolume
metadata:
name: azurefile
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
storageClassName: azurefile
azureFile:
secretName: azure-secret
shareName: aksshare
readOnly: false
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=1000
- gid=1000
- mfsymlinks
- nobrl
Dynamically create and use a persistent volume with Azure Files. Docs here
In this case StorageClass need to have mountOptions
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: my-azurefile
provisioner: kubernetes.io/azure-file
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=0
- gid=0
- mfsymlinks
- cache=strict
parameters:
skuName: Standard_LRS
Now looking at your yamls It seems you are mixing the manual and dynamic mode because you are creating both PersistentVolume and a StorageClass. I suggest to follow one of the suitable approach and have mountOptions specified properly which is mandatory for both the modes.

Answer 2

Problem solved!
There was a problem with secret I created.
It was created with kubectl apply -f secret.json and accountstoragekey wasn't encoded in base64.
Thanx to Azure Support!