All Products
Search
Document Center

Container Service for Kubernetes:CSI storage FAQ

Last Updated:Jan 08, 2026

This topic lists frequently asked questions about mounting and using persistent volumes with Container Storage Interface (CSI) components.

Typical issues

If a pod is in an abnormal state or a persistent volume fails to mount, see Troubleshoot storage issues for troubleshooting steps.

The following list describes some typical issues:

Cloud Disk persistent volumes

Category

Issue

Creation

Mounting

Usage

Expansion

Unmounting

Other

NAS persistent volumes

Category

Issue

Mounting

Usage

Unmounting

Unmount times out and pod is stuck in Terminating state

OSS persistent volumes

ossfs 1.0

Type

Issue

Mounting

Usage

Scaling

Do I need to scale out a volume when the actual storage capacity exceeds the volume's configuration?

Uninstall

Unmounting a statically provisioned OSS volume fails and the pod remains in the Terminating state

ossfs 2.0

Category

Question

Mount

Scale out

Do I need to scale out a volume when the actual storage capacity exceeds the volume's configuration?

Usage

How to restart the ossfs 2.0 process

Storage components

Type

Issue

Component issues

Component upgrade failures

CNFS

An "IPAddress ... for Service ... has a wrong reference" event alert appears after an ACK cluster upgrade

Symptom

After you upgrade the cluster, running the kubectl get events -A command may return continuous Warning events:

IPAddress: <IP_ADDRESS> for Service kube-system/cnfs-cache-ds-service has a wrong reference; cleaning up

This issue usually occurs in the following scenarios:

  1. The version of the storage-operator component in the cluster is earlier than v1.33.1.

  2. The cluster is upgraded from a version earlier than 1.33 to version 1.33 or later.

Cause

Versions of storage-operator earlier than v1.33.1 have a known issue where they continuously try to create an existing Service. In Kubernetes 1.33 and later, the MultiCIDRServiceAllocator feature is enabled by default. This repetitive behavior triggers the feature, causing the system to enter a loop of rapidly creating and deleting temporary IPAddress resources.

Solution

Upgrade the storage-operator component.

Why is the kube-system/cnfs-cache-ds-service automatically recreated after I manually delete it?

Symptom

You manually delete the cnfs-cache-ds-service in the kube-system namespace. The deletion operation appears to succeed, but the service reappears shortly after.

Cause

This issue is caused by the storage-operator component, which works as follows:

  1. Desired state: In the storage-operator ConfigMap, the installation status of cnfs-cache-ds-service is defined as true.

  2. Continuous monitoring: The component continuously checks the cluster to ensure that the service exists.

  3. Automatic reconciliation: When you manually delete the service, the controller detects that the actual state does not match the desired state. It then immediately recreates the service to match the desired state.

Solution

Method 1: Upgrade the storage-operator component (Recommended)

For more information, see Upgrade the storage-operator component.

Method 2: Modify the storage-operator configuration (Temporary solution)

This method involves modifying the storage-operator configuration file to prevent the cnfs-cache-ds service from being automatically recreated.

  1. Find and edit the storage-operator ConfigMap in the kube-system namespace.

    kubectl edit configmap storage-operator -n kube-system
  2. In the data field, locate cnfs-cache-ds and change the value of its install key from true to false.

    cnfs-cache-ds:
      install: "false"
      # ...other configurations...
  3. Save the changes and exit the editor. The storage-operator then applies the new configuration.

  4. Run the command to delete the service again.

    kubectl delete service cnfs-cache-ds-service -n kube-system