Accessing Azure File Share from local Kubernetes cluster

Question

OS: Windows 10  
Kubernetes version: 1.14.8  
Helm version: 3  
Docker Desktop version: 2.1.0.5

Trying to deploy a Kubernetes cluster using a Helm-chart that contains a pod that connects to a statically provisioned Azure File Share. Deploying to an Azure Kubernetes cluster works, but when we try to deploy the cluster locally on docker-desktop it gets the error message when trying to mount the share:

Unable to mount volumes for pod "": timeout expired waiting for volumes to attach or mount for pod "". list of unmounted volumes=[servicecatalog-persistent-storage]. list of unattached volumes=[interactor-properties servicecatalog-persistent-storage default-token-9fp7j]

Mounting arguments: -t cifs -o username=,password=,file_mode=0777,dir_mode=0777,vers=3.0 //.file.core.windows.net/spps /var/lib/kubelet/pods/44a70ebf-1b26-11ea-ab13-00155d0a4406/volumes/kubernetes.io~azure-file/servicecatalog-spp-pv Output: mount error(11): Resource temporarily unavailable

Helm charts (removed redundant information):

Deployment:

apiVersion: apps/v1
kind: Deployment
spec:
    spec:
      containers:
        - name: {{ .Release.Name }}-{{ .Chart.Name }}
          volumeMounts:
            - name: servicecatalog-persistent-storage
              mountPath: /data/sppstore
      volumes:
        - name: servicecatalog-persistent-storage
          persistentVolumeClaim:
            claimName: servicecatalog-pv-claim

Persistent Storage / Claims:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: servicecatalog-spp-pv
  labels:
    usage: servicecatalog-spp-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  azureFile:
    secretName: azurefile-secret
    shareName: spps
    readOnly: false

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: servicecatalog-pv-claim
  annotations:
    volume.beta.kubernetes.io/storage-class: ""
  storageClass: 
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  selector:
    matchLabels:
      usage: servicecatalog-spp-pv

Secret:

apiVersion: v1
kind: Secret
metadata:
  name: azurefile-secret
type: Opaque
data:
  azurestorageaccountname: <acc name>
  azurestorageaccountkey:<acc key>

We have tried:

Using the Azure File Diagnostics to ensure ports are open and we are able to connect from our machine. link
Connecting using Azure Storage Explorer (works)

Microsoft says that connecting to an Azure File Share locally requires SMB 3.0 for security reasons which Windows 10 supports, but Kubernetes seems to use CIFS (which is a dialect of SMB?), but we cant figure out if its supported for access to Azure File Share. Any ideas?

Hi @Marius is this working? I am having the same problem. – Saurabh Feb 11 '21 at 07:21 — Saurabh, Feb 11 '21 at 07:21

score 2 · Answer 1 · answered Dec 10 '19 at 09:27

The recommended way to mount an Azure file share on Linux is using SMB 3.0. By default, Azure Files requires encryption in transit, which is only supported by SMB 3.0. Azure Files also supports SMB 2.1, which does not support encryption in transit, but you may not mount Azure file shares with SMB 2.1 from another Azure region or on-premises for security reasons.

https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-linux

so if you are using smb 2.1 you can only mount the file share from inside the same region. not from local workstation or from another azure region

since your cifs mount mentions vers=3.0 - I would assume this should work in your case. check storage account network access restrictions? or your network restrictions. say port 445, or other concerns mentioned in the linked article

Thanks for your reply. We have successfully connected to the file share using Azure Storage Explorer as well as run through the [diagnostics script](https://gallery.technet.microsoft.com/Troubleshooting-tool-for-a9fa1fe5) with everything lookin good (SMB version 3.1.1, ports open, storage account resolves to an IP). But this is of course from the Windows host and not within a container. As you mention, cifs says vers=3.0 and if that is telling to what smb version is used it *should have worked*, but doesn't. — Marius Wiik, Dec 10 '19 at 11:43
right, but, testing using from windows does not really prove anything ;) — 4c74356b41, Dec 10 '19 at 11:45

Accessing Azure File Share from local Kubernetes cluster

1 Answers1