> ## Documentation Index
> Fetch the complete documentation index at: https://docs-v2.ard.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Mountpoint `/data` not working

> Complete troubleshooting guide for GlusterFS mountpoint issues in ModMS

If the GlusterFS mountpoint at `/data` is not accessible, follow this comprehensive recovery process.

## Step 1: Recover

The primary recovery step that uses your fstab configuration:

```bash theme={null}
cd / && umount -l /data || true; mount /data
```

**What this does:**

* Changes to root directory (`cd /`)
* Lazy unmounts `/data` if mounted (`umount -l /data || true`)
* Mounts `/data` using your fstab configuration (`mount /data`)

**Fstab Configuration:**
Your fstab is configured with primary and backup servers:

```bash theme={null}
cat /etc/fstab
```

Expected output:

```
n01.modms:/gv0 /data glusterfs defaults,_netdev,backupvolfile-server=n02.modms 0 0
```

This configuration:

* Uses `n01.modms` as the primary volfile server
* Falls back to `n02.modms` if the primary is unavailable
* Sets `_netdev` to ensure network is available before mounting

## Step 2: Verify

After recovery, verify the mountpoint is working correctly:

<CodeGroup>
  ```bash Check Mount Source theme={null}
  findmnt -T /data
  ```

  ```bash Check Disk Usage theme={null}
  df -h /data
  ```

  ```bash Check Heal Status theme={null}
  gluster volume heal gv0 info
  ```

  ```bash Check Peer Status theme={null}
  gluster peer status
  ```
</CodeGroup>

### Verification Criteria

**Mount Source (`findmnt -T /data`):**

* **OK** if SOURCE shows `n01.modms:/gv0` or `n02.modms:/gv0`
* Either source is acceptable; it indicates which volfile server was used

**Disk Usage (`df -h /data`):**

* **OK** if size ≈ 7.0T and usage matches n02 (\~3.2–3.3T)
* Verifies the filesystem is accessible and shows expected capacity

**Heal Status (`gluster volume heal gv0 info`):**

* **OK** if `Number of entries: 0` for all bricks
* Indicates no pending heal operations (data is consistent)

**Peer Status (`gluster peer status`):**

* **OK** if both peers are connected
* Shows `n01.modms` and `n02.modms` are in the cluster

## Step 3: If Mount Still Fails

If Step 1 doesn't resolve the issue, run these commands in order and retry **Step 1**:

<Steps>
  <Step title="Restart Gluster Service">
    ```bash theme={null}
    systemctl restart glusterd
    ```

    Restarts the GlusterFS daemon service.
  </Step>

  <Step title="Check Peer Status">
    ```bash theme={null}
    gluster peer status
    ```

    Verify both peers are connected after restart.
  </Step>

  <Step title="Check Volume Status">
    ```bash theme={null}
    gluster volume status gv0
    ```

    Ensure the volume is started and all bricks are online.
  </Step>

  <Step title="Retry Mount">
    Retry Step 1:

    ```bash theme={null}
    cd / && umount -l /data || true; mount /data
    ```
  </Step>
</Steps>

### Optional: Force Mount

If the standard mount still fails, you can force mount using a specific peer:

```bash theme={null}
mount -t glusterfs n02.modms:/gv0 /data
df -h
```

<Note>
  Seeing `n02.modms:/gv0` in the mount output is normal if you mounted via that peer. It only indicates the volfile server used. I/O still goes to all bricks in the replicated volume.
</Note>

**What this does:**

* Forces mounting using `n02.modms` as the volfile server
* Bypasses fstab configuration
* Useful when primary server (`n01.modms`) is unavailable

## Troubleshooting Checklist

<AccordionGroup>
  <Accordion title="Service not running">
    If `systemctl status glusterd.service` shows the service as inactive:

    ```bash theme={null}
    systemctl start glusterd.service
    systemctl enable glusterd.service
    ```
  </Accordion>

  <Accordion title="Volume not started">
    Check if the GlusterFS volume is started:

    ```bash theme={null}
    gluster volume status gv0
    ```

    If the volume is stopped, start it:

    ```bash theme={null}
    gluster volume start gv0
    ```
  </Accordion>

  <Accordion title="Network connectivity issues">
    Ensure all GlusterFS nodes can communicate:

    ```bash theme={null}
    ping n01.modms
    ping n02.modms
    ```

    Check firewall rules to ensure GlusterFS ports are open (default: 24007, 24008, and dynamic ports).
  </Accordion>

  <Accordion title="Peer disconnected">
    If peers show as disconnected:

    ```bash theme={null}
    gluster peer probe n01.modms
    gluster peer probe n02.modms
    ```

    Then verify:

    ```bash theme={null}
    gluster peer status
    ```
  </Accordion>
</AccordionGroup>

## Understanding the Mount Process

**Volfile Server vs. Data Bricks:**

* The volfile server (`n01.modms` or `n02.modms`) provides configuration
* Actual data I/O goes to all bricks in the replicated volume
* Mounting via either peer is functionally equivalent

**Fstab Configuration:**

* `backupvolfile-server=n02.modms` provides automatic failover
* If `n01.modms` is unavailable, it automatically tries `n02.modms`
* `_netdev` ensures network is ready before mounting

## Related Topics

* [Why is GlusterFS used?](/data-ai/modms/faq/why-glusterfs)
* [GlusterFS Commands](/data-ai/modms/faq/glusterfs-commands)
* [Volume Status Example](/data-ai/modms/faq/volume-status-example)
* [Architecture Overview](/data-ai/modms/architecture)