This topic is applicable only to Linux. Windows users can skip this topic.

Step 1: Check whether the noresvport parameter is specified

  1. Download the check_noresvport.py script to an ECS instance that encounters mount issues.
    wget -N https://code.aliyun.com/nas_team/nas-client-tools/raw/master/linux_client/check_alinas_nfs_mount.py -P /tmp/
  2. Use the following command to run the check_noresvport.py script.
    python2.7 /tmp/check_noresvport.py -e

    If a message showing "There is no issue for 'noresvport' on this ECS" appears, skip the following steps. Otherwise, proceed with Step 2: Resolve a mount issue related to the noresvport parameter.

Step 2: Resolve a mount issue related to the noresvport parameter during off-peak hours

  • If you mount an Apsara File Storage NAS on an ECS instance, use the following command to run the script again.
    python2.7 /tmp/check_noresvport.py -e -r
  • If you mount an Apsara File Storage NAS on a container, use the following command to run the script again on the node where the container resides.
    python2.7 /tmp/check_noresvport.py -e -c

Step 3: Update settings for an automatic mount

After the preceding steps are complete, process with Step 1: Check whether the noresvport parameter is specified and verify the result. If you have any further questions, join the Dingtalk group 2311076 to contact Alibaba Cloud Customer Service.

FAQ

  • Why do I need to mount an Apsara File Storage NAS file system by using the noresvport parameter? What happens if I do not mount the file system again?

    If network switchovers or high availability (HA) switchovers of backend services occur, the network of the file system has a low probability of being disrupted. In most cases, communication is automatically restored within several minutes. In the worst scenarios, you may need to restart the ECS instance to restore communication. However, communication is automatically restored within several seconds if the noresvport parameter is specified.

  • In which types of cases do network switchovers or HA switchovers of backend services occur?

    Apsara File Storage NAS provides stable and continuous file storage services. However, network switchovers or HA switchovers for backend services may still occur with a low probability. HA switchovers for backend services may occur due to service upgrades. The client network has a low probability of being disrupted due to these switchovers. Before service upgrades, we take preventative measures by sending notifications to the relevant users about the upgrade schedules. We recommend that you apply the noresvport parameter at your earliest opportunity. If no upgrades is scheduled at the backend, applying the noresvport parameter prevents against failures of file systems due to other unexpected issues. These issues include changes on Server Loader Balancer (SLB) instances, hardware failures at the backend, and other cases that may trigger switchovers.

  • Why must I mount the file system again? Are other solutions to the issue available?

    You must disconnect all previous TCP connections to the file system before mounting the file system again. To ensure that the noresvport parameter takes effect, you must remove all previous TCP connections before establishing new TCP connections. To remove all previous TCP connections, you must stop all services that are related to Apsara File Storage NAS, and then use the umount command to unmount the file system.If you do not want to mount the file system again, we recommend that you create a new mount target for the file system. Then, you need to mount the new mount target on another local directory. Before dropping the previous local directory and mount target, you must migrate all services to the new local directory in batches.