Skip to main content
Two kinds of storage live outside the supervisor’s nodes: NFS mounts an export from a NAS, and a Fibre Channel array presents LUNs that the nodes see. NFS is a family tab on the wizard’s Storage step and reports through the standard component status model. An array’s LUNs go under LINSTOR or Ceph; see Fibre Channel.

NFS

The NFS tab installs the CSI NFS driver (csi-driver-nfs, in kube-system) and creates a StorageClass per export: The driver installs once; StorageClasses are applied independently, so you can save a class, smoke-test it, adjust, and re-apply without reinstalling anything. Multiple exports become multiple classes on the same driver.

Why the default mount options are what they are

Both surprising parts of that default were chosen against measurements, and changing either of them has bitten before. nfsvers=3, not 4.1. A NAS that registers only nfsd versions 2 and 3 — which is how TrueNAS ships — rejects a 4.1 mount with Protocol not supported. The failure is quiet in the worst way: the PVC sits Pending and the real reason is in an event on the claim, not in the storage panel. Version 4.1 also buys nothing for these volumes; it is not the throughput lever it is usually assumed to be. Raise it only if you know your server answers on it. nconnect=4. Without it every PVC on a node shares a single TCP stream to the server, which measured a ceiling around 200–270 Mbps and head-of-line blocking between VM disk IO and image-clone traffic. It costs nothing on any kernel from 5.3 onward.
nconnect applies when a node establishes a new transport — the first mount after a boot or a full unmount. Adding it to an existing class does not change the connection count on a node that already has the export mounted, so a node that shows no improvement has probably not remounted yet.

The test PVC

Run smoke test creates a 1 GiB PVC on the class, waits for it to bind, writes to it, and deletes it. On failure it returns the claim’s events — the actual mount.nfs, DNS, or firewall error from the provisioner — so a misconfigured server or an unreachable export is diagnosed in the panel, not in kubectl. Run it after every apply; an NFS class that binds the smoke-test claim will bind real workloads.

Status and orphans

The NFS status carries the driver’s HelmRelease block plus every NFS StorageClass with its server and share. Before anything is installed the shape is minimal and honest:
A StorageClass whose driver release is missing or not ready is flagged orphan: it looks valid, PVCs can reference it, and nothing will ever bind. The panel offers deletion for orphan classes — the one StorageClass delete operation in the product, deliberately scoped to NFS orphans.

What commonly goes wrong

Fibre Channel

Celum does not carve an array volume per PVC on a Hitachi VSP. Carve a few large LUNs on the array once, mask them to the nodes, and put a software-defined backend on them:
  • LINSTOR: the Shared array LUN option of a LINSTOR card builds a pool on one LUN that every node sees, with the linstor-san class. Snapshots and live migration come from LINSTOR. See LINSTOR.
  • Rook-Ceph: the san device class turns LUNs into Ceph OSDs.
Either way the array is out of the runtime path: Celum never calls its API. Infrastructure & nodes shows each node’s FC ports and the LUNs it sees.
The Hitachi VSP (Celum CSP) card, which carved one array volume per PVC through the HPE CSI driver, was removed in 1.311.0: installed from Celum, it never started.

Permissions

LINSTOR

A shared array LUN as the linstor-san pool, next to replicated local NVMe.

Rook-Ceph

FC array LUNs as Ceph OSDs, array out of the runtime path.

Classes & profiles

What NFS and FC classes can and cannot back — access modes, volume modes, clone strategy.

Infrastructure & nodes

FC port state and the SAN LUN multipath picture per node.

Storage overview

Choosing between the three backends.