Unable to create SMB PVs - "Already existing volume name with different capacity"

[bogd]

I am entirely unable to create SMB PVs . After creating the secret, storage class, and PVC, the PV is never created, and the error below is logged:

  Type     Reason                Age              From                                                             Message
  ----     ------                ----             ----                                                             -------
  Normal   ExternalProvisioning  7s (x3 over 8s)  persistentvolume-controller                                      waiting for a volume to be created, either by external provisioner "csi.san.synology.com" or manually created by system administrator
  Normal   Provisioning          4s (x3 over 8s)  csi.san.synology.com_mpc01_c4b84a4f-d2b0-46f6-95f8-ae3f75e7ad4f  External provisioner is provisioning volume for claim "default/ubuntu-test"
  Warning  ProvisioningFailed    3s (x3 over 7s)  csi.san.synology.com_mpc01_c4b84a4f-d2b0-46f6-95f8-ae3f75e7ad4f  failed to provision volume with StorageClass "synostorage-smb": rpc error: code = AlreadyExists desc = Already existing volume name with different capacity

However, something does actually get created on the Synology device - if I go to ControlPanel / Shared Folders, I see the k8s-csi-pvc-.... folders. But no corresponding PV shows up on K8s.

The manifests I am using are below:

apiVersion: v1
kind: Secret
metadata:
  name: cifs-csi-credentials
  namespace: synology-csi
type: Opaque
stringData:
  username: testuser  # DSM user account accessing the shared folder
  password: testpass  # DSM user password accessing the shared folder

---

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: synostorage-smb
provisioner: csi.san.synology.com
parameters:
  protocol: smb
  csi.storage.k8s.io/node-stage-secret-name: cifs-csi-credentials
  csi.storage.k8s.io/node-stage-secret-namespace: synology-csi
reclaimPolicy: Delete
allowVolumeExpansion: true

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ubuntu-test
  labels:
    app: containerized-data-importer
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-arm64.img
spec:
  storageClassName: synostorage-smb
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

[xphyr]

@bogd I have run into this same issue. There are two things happening that I can tell:

1. I am assuming that you are using a synology array that uses ext4 for the filesystem format (not brtfs). ext4 does not support quotas per volume, so while a quota is applied at creation its ignored. Thus you end up with the "existing volume with different capacity". Can you validate that the volume you are using is in fact an ext4 volume?
2. The call to create the new SMB share is taking WAY to long to run (in my case over two minutes for some reason) and the CSI driver is timing out before the call completes. The quick fix here is to update this line: https://github.com/SynologyOpenSource/synology-csi/blob/main/deploy/kubernetes/v1.20/controller.yml#L96 and change 60s to 300s. This gives the Synology enough time to process the request and return a response to the CSi Controller

To set expectations, I am just a end user of this driver myself, but I am going to see if I can fix both of these issues...

[bogd]

@xphyr - thank you for your reply!

1. You might be on to something here... I am using btrfs on most of my synology devices, but for this test I used an older unit that only supports ext4 .
2. Not sure about this one - I never got to the point of actually getting a timeout. It exits way before that, with the "existing volume" error.

To be honest, this was a... disappointing experience for me. At first I was happy to see that Synology (unlike other vendors, such as QNAP) has a native CSI provider. But after trying it, this seems half-baked as best:

• bugs affecting SMB volumes
• the horrendous limitations on iSCSI volumes (one volume per target? so... 10 volumes in total for the entire unit?? That is way below even normal home lab usage... )
• an almost complete lack of support for the project (I was not able to find an answer from the contributors on any of the issues, and there are issues posted one year ago with zero comments!)

So in the end, I just gave up on it. I am still using the Synology unit, but simply as an NFS server, with the NFS CSI provisioner on top. It works fine for my purposes (homelab), even with the lack of a quota on the volume.

Thank you once again!

[xphyr]

@bogd Thanks for the feedback. I agree there are some big limitations here, and support for this project is spotty at best. There is another CSI driver that supports the synology (https://github.com/democratic-csi/democratic-csi). The democratic-csi driver appears to only support iSCSI at this time, but there may be other things in the works. (I believe the developer of that driver watches this project as well ...)

I spent some time looking at this last night, and am working through a bunch of different issues, including upgrading the build chain to a modern version of Go, and merging in some of the other pull requests that are pending here to my fork to see if I can pull together a more stable version of the app. I like to simulate larger arrays for my home lab, and that is why I am trying to get this to work. The SMB is especially interesting to me as I am also working with Windows Containers in K8s, and this driver should be able to supply persistent storage across both Linux and Windows Platforms.

Ultimately, I think you may have the right idea just using NFS and the NFS CSI provisioner.

Wish me luck.

[chihyuwu]

On a Synology array, the shared folder created on an ext4 volume does not support :

• setting quotas
• snapshotting
• cloning

Currently, the synology-csi does not prevent these limitations, leading to unclear error messages. We sincerely apologize for any inconvenience caused. We acknowledge this issue and have plans to improve the situation in the future. :bow:

[rtim75]

The call to create the new SMB share is taking WAY to long to run (in my case over two minutes for some reason) and the CSI driver is timing out before the call completes.

this can be fixed using format options in storageClass which were added in #49

For ext4 fs:

parameters:
  fsType: 'ext4'
  formatOptions: "-E nodiscard"
  protocol: 'iscsi'

For btrfs fs:

parameters:
  fsType: 'btrfs'
  formatOptions: "--nodiscard"
  protocol: 'iscsi'