Windows SMB Mount Error with ONTAP-NAS-ECONOMY driver

[burkhat]

Describe the bug Hello, we've created a Trident SMB Backend with storageDriverName "ontap-nas-economy".

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nas-economy-smb-s-mu40-trident0
  namespace: trident
spec:
  credentials:
    name: trident-backend
  dataLIF: 10.0.3.27
  labels:
    netapp: S-MU40-trident0-smb
  managementLIF: 10.0.3.25
  nasType: smb
  storageDriverName: ontap-nas-economy
  svm: S-MU40-trident0
  version: 1

After that we've created a StorageClass with this Backend:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: file-smb-no-backup
provisioner: csi.trident.netapp.io
parameters:
  backendType: ontap-nas-economy
  csi.storage.k8s.io/node-stage-secret-name: trident-smb-backend
  csi.storage.k8s.io/node-stage-secret-namespace: trident
  selector: netapp=S-MU40-trident0-smb
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

From the StorageClass we created a PVC without any problem:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test
  namespace: cocdit-windows-tests-sepp
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  volumeName: pvc-85b4a4af-2080-483b-8768-6f356e4b4fc4
  storageClassName: file-smb-no-backup
  volumeMode: Filesystem
status:
  phase: Bound
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 2Gi

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pvc-85b4a4af-2080-483b-8768-6f356e4b4fc4
spec:
  capacity:
    storage: 2Gi
  csi:
    driver: csi.trident.netapp.io
    volumeHandle: pvc-85b4a4af-2080-483b-8768-6f356e4b4fc4
    volumeAttributes:
      backendUUID: 7a8e8590-6f11-49c9-b97c-d72f277fbe58
      internalID: >-
        /svm/S-MU40-trident0/flexvol/trident_qtree_pool_trident_LUHYWDEPZB/qtree/trident_pvc_85b4a4af_2080_483b_8768_6f356e4b4fc4
      internalName: trident_pvc_85b4a4af_2080_483b_8768_6f356e4b4fc4
      name: pvc-85b4a4af-2080-483b-8768-6f356e4b4fc4
      protocol: file
      storage.kubernetes.io/csiProvisionerIdentity: 1686642052713-8081-csi.trident.netapp.io
    nodeStageSecretRef:
      name: trident-smb-backend
      namespace: trident
  accessModes:
    - ReadWriteMany
  claimRef:
    kind: PersistentVolumeClaim
    namespace: cocdit-windows-tests-sepp
    name: test
    uid: 85b4a4af-2080-483b-8768-6f356e4b4fc4
    apiVersion: v1
    resourceVersion: '596621711'
  persistentVolumeReclaimPolicy: Delete
  storageClassName: file-smb-no-backup
  volumeMode: Filesystem
status:
  phase: Bound

Now we tried to mount the PVC into a POD and we got following error: Error: failed to create containerd task: failed to create shim task: failed to eval symlinks for mount source "\\\\10.0.3.27\\trident_qtree_pool_trident_LUHYWDEPZB\\trident_pvc_85b4a4af_2080_483b_8768_6f356e4b4fc4": Access is denied.: unknown It looks like that it try to mount the Share via a Symlink (DFS), but the command "New-SmbGlobalMapping" doesn't support it: https://serverfault.com/questions/1114471/why-cannot-i-map-an-dsf-smb-share-using-new-smbglobalmapping

Environment Provide accurate information about the environment to help us reproduce the issue.

• Trident version: 23.04
• Trident installation flags used: deployed with the Helm Chart
• Container runtime: containerd
• Kubernetes version: v1.25.8+37a9a08
• Kubernetes orchestrator: Openshift 4.12
• Kubernetes enabled feature gates: -
• OS: RHEL 8, Windows Server 2022
• NetApp backend types: ONTAP-NAS-ECONOMY
• Other:

To Reproduce See Bug description

Expected behavior That a Symlink won't be used and it is possible to mount the Share. Maybe there is a setting in Trident / NetApp that the full Path will be mounted, at the moment I cannot find

Additional context With storagedriver ONTAP-NAS everything works fine.