Even if user explicitly requires the same fsGroup as runAsUser and runAsGroup for a Pod:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1002
    runAsGroup: 1002
    fsGroup: 1002

he/she will fail to write to the volume:

bash-5.2$ touch /mnt/claim/FILE
touch: cannot touch '/mnt/claim/FILE': Permission denied

if StorageClass does not set uid/gid or dir_mode or noperm:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: samba
provisioner: smb.csi.k8s.io
parameters:
  source: //samba-server.samba-server.svc.cluster.local/share
  csi.storage.k8s.io/provisioner-secret-name: smbcreds
  csi.storage.k8s.io/provisioner-secret-namespace: samba-server
  csi.storage.k8s.io/node-stage-secret-name: smbcreds
  csi.storage.k8s.io/node-stage-secret-namespace: samba-server
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - file_mode=0777
  - mfsymlinks
  - cache=strict
  - noserverino

    100%

    See reproducer in upstream issue: https://github.com/kubernetes-csi/csi-driver-smb/issues/835     

    An attempt to write inside the volume fails.

    User can write data to the volume.