Skip to main content

File Storage troubleshooting

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

Mount errors​

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

Mount point does not exist​

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

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

▶️ Solution

  1. Verify that Mount PATH is correct.
  2. If path does not exist, create mount target directory using following command.
mkdir -p {Mount PATH}
  1. Retry mount.

Already mounted​

File system is already mounted.

mount.nfs: ... already mounted

▶️ Solution

  1. Run 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 above example, /mnt/my_nfs path indicates that 192.168.1.100:/export/nfs/share is already mounted. File system type is nfs, and permission is set to rw (read/write).

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

  3. If existing mount needs to be removed, run following command to unmount.

    umount {Mount PATH}

    Example result

    $ umount /mnt/my_nfs

    After unmount, run mount command again and confirm that /mnt/my_nfs is no longer displayed.

Access denied or connection timed out​

Client IP to mount is not allowed in File Storage access control settings, or network connectivity issue may exist between client and File Storage.

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

▶️ Solution

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

  2. Verify network connectivity between client instance and File Storage.

    • Check port
    telnet {File Storage IP} 2049
    • If telnet command fails, check following:
      • Verify that inbound traffic on port 2049 (NFS) is allowed in client security group
      • Verify that client and File Storage are in same subnet or routing and security group settings are properly configured
      • Verify that network ACL does not block NFS traffic

  3. If issue persists after checking above steps, review 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.

▶️ Solution

  1. Download script file using following command in NFS client environment.

    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 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 is successfully completed. If checksum values differ, issue may have occurred during data transfer.

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