Managed CSI driver mounting folder structure issues

[gudejagadeesh123]

We are currently facing issues with the CSI SMB driver involving persistent volume (pv) and persistent volume claim (pvc) mounts, which are causing application job failures with the error: "MountVolume.SetUp failed for volume."
After discussing this with Microsoft, they suggested transitioning to a Microsoft-managed CSI driver. However, it's important to note that the newer Azure CSI driver supports mapping only to the root directory of a file share. This limitation poses significant challenges for existing infrastructure that relies on segmented folder structures.

Key Challenges

1. Loss of Subdirectory Mounting Capability
   Current state: CSI SMB driver enables mounting directly to subfolders within an Azure Storage account's file share.
   Change: Azure CSI driver restricts mounting to the file share's root directory only.
   Impact: This eliminates the ability to isolate storage at a granular level per environment, application, or namespace without provisioning multiple file shares.

2. Complex Environment Reconfiguration
   Many production and non-production environments currently depend on folder-level isolation.
   Migrating to root-level mapping requires:
   Rearchitecting folder hierarchies
   Reprovisioning PVCs and PVs

Example folder structure
refer below screenshot

Please clarify on key challenges which mentioned above for implement managed CSI driver.

[david-garcia-garcia]

@gudejagadeesh123 we are doing something similar using the folderName volume attribute.

Only caveat is that the driver requires that the target directory already exists or it will fail to mount. This is a total pain depending on the tooling you use for the infrastructure.

There was a feature request for this:

#1296

The original feature request was closed automatically due to staleness.

[lesio999]

@david-garcia-garcia can you please paste here some examples of your usage? is it in PV/PVC? or directly in yamls?

[david-garcia-garcia]

@lesio999 please refer to the driver parameters for more detail:

https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/docs/driver-parameters.md

It works with both PVC and inline volumes.

An alternative which I found useful is to map to the root of the share in the inline volume, and then use the volumeMount itself to map to a subdirectory using subPath:

    volumeMounts:
    - mountPath: /opt/magento/pub/static/_cache
      name: data
      subPath: magentoprod244/magento/static_cache
    - mountPath: /opt/magento/var
      name: data
      subPath: magentoprod244/magento/var
    - mountPath: /opt/magento/pub/media
      name: data
      subPath: magentoprod244/magento/media

In this previous example all volume mounts are sharing the same csi file share volume, but each one of them is mounted to a different location, both in the container and in the share itself.

Advantage of using subPath is that if the directory does not exist, it will be automatically created.

So you can either:

• Specify folderName in the volume properties
• Do not specify folder name, and then use subPath when mounting the volume

Sometimes you do not have control on who is consuming the PVC (like when you feed a Helm Chart) or inline volume, in those cases you need to use folderName and ensure the path exists otherwise it won't mount.

[lesio999]

@david-garcia-garcia - thanks a lot