search

NetApp / trident

Storage orchestrator for containers
Apache License 2.0
762 stars 222 forks source link

Windows SMB Mount Error with ONTAP-NAS-ECONOMY driver #832

Closed burkhat closed 2 weeks ago

burkhat commented 1 year ago

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.

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.

sjpeeris commented 3 weeks ago

Hi @burkhat Please let us know if this issue still exists with the newer versions of Trident. If not, please close the issue.

sjpeeris commented 2 weeks ago

Closing. Please re-open if you notice this issue with newer versions of Trident.