<pre><code>OS: Windows 10  
Kubernetes version: 1.14.8  
Helm version: 3  
Docker Desktop version: 2.1.0.5
</code></pre>

<p>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:</p>

<blockquote>
  <p>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]</p>
  
  <p>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</p>
</blockquote>

<p>Helm charts (removed redundant information):</p>

<p>Deployment:</p>

<pre><code>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
</code></pre>

<p>Persistent Storage / Claims:</p>

<pre><code>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
</code></pre>

<p>Secret:</p>

<pre><code>apiVersion: v1
kind: Secret
metadata:
  name: azurefile-secret
type: Opaque
data:
  azurestorageaccountname: &lt;acc name&gt;
  azurestorageaccountkey:&lt;acc key&gt;
</code></pre>

<p>We have tried:</p>

<ul>
<li>Using the Azure File Diagnostics to ensure ports are open and we are able to connect from our machine. <a href="https://gallery.technet.microsoft.com/Troubleshooting-tool-for-a9fa1fe5" rel="nofollow noreferrer">link</a>  </li>
<li>Connecting using <a href="https://azure.microsoft.com/en-us/features/storage-explorer/" rel="nofollow noreferrer">Azure Storage Explorer</a> (works)</li>
</ul>

<p>Microsoft says that connecting to an Azure File Share locally <a href="https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows" rel="nofollow noreferrer">requires SMB 3.0 for security reasons</a> 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?</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p><a href="https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-linux" rel="nofollow noreferrer">https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-linux</a></p>

<p>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</p>

<p>since your cifs mount mentions <code>vers=3.0</code> - 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</p>
