Skip to main content

File Storage troubleshooting

This document provides methods to resolve issues that may occur while using File Storage.

Mount errors​

If mount fails or does not work as expected, refer to causes and solutions below.

Mount point does not exist​

The mount target path Mount PATH does not exist or is incorrectly specified.

Error message
mount.nfs: mount point {Mount PATH} does not exist

To resolve the issue:

  1. Verify that Mount PATH is correct.

  2. If the path does not exist, create the mount target directory using the following command.

    mkdir -p {Mount PATH}

  3. Retry the mount.

Already mounted​

The file system is already mounted.

Error message
mount.nfs: ... already mounted

To resolve the issue:

  1. Run the mount command to check currently mounted file systems.

    mount | grep {Mount PATH}

    Example result

    $ mount | grep /mnt/my_nfs
    192.168.1.100:/export/nfs/share on /mnt/my_nfs type nfs (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.101,local_lock=none)

    In the example above, the /mnt/my_nfs path indicates that 192.168.1.100:/export/nfs/share is already mounted.

  2. If an additional mount is not required, keep the existing mount.

  3. If the existing mount must be removed, run the following command.

    umount {Mount PATH}

    After unmounting, run the mount command again. If /mnt/my_nfs is no longer displayed, the file system has been unmounted successfully.

Access denied or connection timed out​

This can occur when the client IP address to mount from is not allowed in File Storage access control settings, or when a network connectivity issue exists between the client and File Storage.

Error message
mount.nfs: ... access denied or Connection timed out

To resolve the issue:

  1. Check File Storage access control settings and add the client IP address to the allow list.

  2. Verify that the client instance can communicate with File Storage.

    telnet {File Storage IP} 2049

  3. If the telnet command fails, check the following:

    • Verify that inbound traffic on port 2049(NFS) is allowed in the client's security group.
    • Verify that the client and File Storage are in the same subnet, or that routing and security group settings are configured correctly.
    • Verify that the network ACL does not block NFS traffic.

  4. If the issue persists after checking the steps above, review the logs and contact Helpdesk.

Checksum mismatch​

If checksum of source data and copied data does not match during data copy through mounted path, data integrity issue may have occurred.

To resolve the issue:

  1. Download the script file using the following commands in the NFS client environment.

    Download checksum script
    curl -O https://objectstorage.kr-central-2.kakaocloud.com/v1/c11fcba415bd4314b595db954e4d4422/public/docs/file_storage/checksum_inspection.sh
    chmod +x checksum_inspection.sh

  2. Run the downloaded script to compare Source File Checksum and Remote NAS Destination Checksum.

    ./checksum_inspection.sh {source-file-path} {remote-nas-file-path}

    Example result

    Remote NAS file checksum matches the source file.
    Checksum matched for iteration 58. Continuing to next iteration.
    -------------------------------------
    Iteration: 59
    1024+0 records in
    1024+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.81003 s, 137 MB/s
    Source File Checksum:              742be2cafe65354d29470fe6dc735df7
    Remote NAS Destination Checksum:   449643df40c7d780060fb2c89aedc37f

  3. If Source File Checksum and Remote NAS Destination Checksum match, data transfer completed successfully. If the checksum values differ, an issue may have occurred during data transfer.

  4. If the issue cannot be resolved through the steps above, contact Helpdesk to request storage recovery.