Skip to main content
Standard NFS File Shares that Managed Kubernetes mounts through the NFS CSI driver must be unmounted before a resize. Resizing a mounted share breaks active NFS mounts with a stale file handle, even when pods remain in the Running state. This procedure covers Standard File Shares already attached to a cluster as a gcore-nfs-* StorageClass. The new size must be larger than the current size, because downsizing is not supported. General resize steps for Virtual Machines and Bare Metal are in configure file shares.

​
Resize limitation

A live resize while pods still mount the share interrupts I/O. The pod may stay Running with zero restarts, while writes fail with Stale file handle. After the share is resized and remounted, new or restarted pods see the expanded capacity. Plan a short maintenance window so workloads that use the PersistentVolumeClaim (PVC) can stop, then start again.

​
Resize procedure

Unmount every workload that uses the PVC, expand the share in the Gcore Customer Portal, then bring the workloads back so Kubernetes remounts the share.
1

Identify workloads

Find every Deployment, StatefulSet, or pod that mounts the PVC backed by the File Share StorageClass.
Note the Deployment or StatefulSet name and the replica count. Those values are needed to restore capacity after the resize.
2

Unmount the share

Scale the workloads to zero replicas, or delete the pods that mount the PVC, so the cluster releases the NFS mount.
Confirm that no pods still mount the PVC before continuing:
3

Resize the File Share

In the Customer Portal, open Cloud → Storage → File Shares, then select the share.In the Overview tab, click Resize, enter a larger size in GiB, and confirm.Wait until the share status returns to Available and the Size field shows the new capacity.
4

Remount workloads

Scale the Deployment or StatefulSet back to the previous replica count, or recreate the pods that use the PVC.
Confirm the pods reach Running:
5

Verify capacity

From a running pod that mounts the PVC, check that the filesystem reports the new size and that read and write operations succeed.
Replace /mnt/data with the mount path used by the application. A successful remount shows the expanded size and accepts new writes without stale file handle errors.