This topic provides answers to some frequently asked questions about Apsara File Storage NAS (NAS) volumes.

Why does the system prompt chown: Operation not permitted when I mount a NAS volume?

Issue

The system prompts chown: Operation not permitted when I mount a NAS file system.

Cause

The role that is used to run the container does not have the permissions to manage the NAS file system.

Solution

The container is launched without root privileges. Log on to the NAS file system as the root user, modify the permissions required by the NAS file system, and then mount the NAS file system to the container again. This ensures that the permissions of the user that is used to run the container are the same as the permissions required by the NAS file system that you want to mount.

What do I do if the task queue of alicloud-nas-controller is full and PVs cannot be created when I use a dynamically provisioned NAS volume?

Issue

When you use a dynamically provisioned NAS volume, if the speed of subdirectory creation is faster than the speed of subdirectory deletion, the task queue of alicloud-nas-controller may be full and therefore persistent volumes (PVs) cannot be created.

Cause

The reclaimPolicy parameter is set to Delete and the archiveOnDelete parameter is set to false in the configuration of the StorageClass that mounts the dynamically provisioned NAS volume.

Solution

Set archiveOnDelete to true. This way, when a PV is deleted, only the name of the mounted subdirectory in the NAS file system is modified. The files in the subdirectory are not deleted.

You must delete these files yourself. For example, you can configure a node to automatically delete files in the root directory by schedule, or start multiple pods to concurrently delete files of specific formats in subdirectories.

Why does it require a long time to mount a NAS volume?

Issue

It requires a long time to mount a NAS volume.

Cause

If the following conditions are met, the chmod or chown operation is performed when volumes are mounted, which increases the time consumption.

  • The AccessModes parameter is set to ReadWriteOnce in the PV and persistent volume claim (PVC) templates.
  • The securityContext.fsgroup parameter is set in the application template.

Solution

  • If the securityContext.fsgroup parameter is set in the application template, delete the fsgroup parameter in the securityContext section.
  • If you want to configure the user ID (UID) and mode of the files in the mounted directory, you can manually mount the directory to an Elastic Compute Service (ECS) instance. You can then perform chown and chmod operations through a CLI and provision the NAS volume through the CSI plug-in. For more information about how to provision NAS volumes through the CSI plug-in, see Mount a statically provisioned NAS volume or Mount a dynamically provisioned NAS volume.
  • Apart from the preceding methods, for clusters of Kubernetes 1.20 or later, you can set the fsGroupChangePolicy parameter to OnRootMismatch. This way, the chmod or chown operation is performed only during the first-time launch of the pod that uses the volume. This reduces the time to mount new OSS volumes to the pod. For more information about the fsGroupChangePolicy parameter, see Set the security context for a container.

What do I do if I cannot modify the directories that are created in a NAS volume?

Issue

You cannot modify the directories that are created in a NAS volume.

Cause

Non-root users do not have the permissions to modify the directories that are created in a PV.

Solution

You can select one of the following methods to run the chmod or chown command to modify the access permissions on the mount directory:

  • Launch an init container with root privileges, mount a PV, and then run the chmod or chown command to modify the access permissions on the mount directory. Then, you can modify the directories that are created in the PV.
  • Set the fsGroupChangePolicy parameter to OnRootMismatch. This way, when the system launches the pod for the first time, the system runs the chmod or chown command to modify the access permissions on the mount directory. Then, you can modify the directories that are created in the PV.

Why does the system prompt unknown filesystem type "xxx" when I mount a NAS volume?

Issue

The system prompts unknown filesystem type "xxx" when you mount a NAS volume.

Cause

The dependencies of the NAS volume are not installed on the node on which the application is deployed.

Solution

Check whether the NAS volume is correctly configured.

Why does the system prompt NFS Stale File Handle when a client reads data from or writes data to a NAS volume?

Issue

The system prompts NFS Stale File Handle when a client reads data from or writes data to a NAS volume.

Cause

NAS does not ensure data consistency after you mount a NAS volume to a container. Assume that a NAS volume is mounted to two clients. Client 1 opens a file in the NAS volume to obtain the file descriptor (FD) of the file. If Client 2 deletes the file, Client 1 cannot read or write the file and the system prompts NFS Stale File Handle.

Solution

You need to resolve data consistency issues based on your business scenarios.

What do I do if a pod that uses two PVCs to mount two different NAS volumes remains in the ContainerCreating state?

Issue

You failed to launch a pod that uses two PVCs to mount NAS volumes and the pod remains in the ContainerCreating state. The pod can be launched if you configure the pod to use only one of the PVCs.

Cause

The two PVs associated with the two PVCs use the same spec.csi.volumeHandle value. As a result, the kubelet cannot differentiate the two PVs when it processes the PV mounting logic.

Solution

Set the spec.csi.volumeHandle parameter of each PV to the actual name of the PV.