Change:
return fmt.Errorf("only cifs mount is supported now, fstype: %q, mounting source (%q), target (%q), with options (%q)", fstype, source, target, options) } <ins> // lock smb mount for the same source getSMBMountMutex.LockKey(source) defer getSMBMountMutex.UnlockKey(source) </ins> if output, err := newSMBMapping(options[0], options[1], source); err != nil { if isSMBMappingExist(source) { klog.V(2).Infof("SMB Mapping(%s) already exists, now begin to remove and remount", source)

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I am using Windows containers (Server Core ltsc 2019). These all have volumes mounted to three different Azure file shares under a single storage account. Multiple instances of these containers run on each node. On deploying the containers I get the following errors. Sometimes this does manage to resolve itself. MountVolume.SetUp failed for volume "log-share" : Remove-SmbGlobalMapping failed: exit status 1, output: "Remove-SmbGlobalMapping : No MSFTSmbGlobalMapping objects found with property 'RemotePath' equal to rn'storageaccounturllogs'. Verify the value of the property and retry.rnAt line:1 char:1rn+ Remove-SmbGlobalMapping -RemotePath $Env:smbremotepath -Forcern+ ~rn + CategoryInfo : ObjectNotFound: (storageaccounturllogs:String) [Remove-SmbGlobalMapping], Ci rn mJobExceptionrn + FullyQualifiedErrorId : CmdletizationQueryNotFoundRemotePath,Remove-SmbGlobalMappingrn rn" MountVolume.SetUp failed for volume "config-share" : New-SmbGlobalMapping failed: exit status 1, output: "New-SmbGlobalMapping : Generic failure rnAt line:1 char:190rn+ ... ser, Env:smbremotepath -Cred ...rn+ ~~~rn + CategoryInfo : NotSpecified: (MSFTSmbGlobalMapping:ROOT/Microsoft/...mbGlobalMapping) [New-SmbGlobalMa rn pping], CimExceptionrn + FullyQualifiedErrorId : HRESULT 0x80041001,New-SmbGlobalMappingrn rn" What you expected to happen: For the volumes to be mounted. This all worked ok in k8s 1.12.1 using Windows 1803. I have now upgraded to 1.13.4 and Windows ltsc2019.

How to reproduce it (as minimally and precisely as possible): Use aks-engine to create a 1.13.4 cluster with Windows nodes Create a storage account Create multiple file shares under the account. Add access credentials to the storage account as a secret on k8s Create a windows container with folders that will be used to mount the Azure storage account file shares. Deploy to k8s defining volume mounts and volumes in the container section of the deployment e.g. volumeMounts: name: folder1-share mountPath: "c:appfolder1" name: folder2-share mountPath: "c:appfolder2" volumes: name: folder1-share azureFile: secretName: azure-file-share-cred shareName: share1 readOnly: false name: folder2-share azureFile: secretName: azure-file-share-cred shareName: share2 readOnly: true Anything else we need to know?: This maybe related to the fix for Environment: Kubernetes version (use ): 1.13.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Windows 2019 Kernel (e.g. ): 10.0..316 Install tools: aks-engine 0.13.2 Others:
/sig Azure
/sig windows
/assign
hi in your logs, the remotepath is , so is the share name? also, could you log on to that agent node, and provide , there are logs like
I think this is a race condition issue, let me file a PR to fix this, thanks for reporting