How to restrict GlusterFS client access

A GlusterFS volume that accepts mounts from every reachable host can expose shared data beyond the intended client network. Restricting client access keeps new native mounts limited to known hosts or source ranges, which matters when storage and application networks are not fully isolated.

Native GlusterFS clients contact a cluster node to fetch the volume file before they connect to the bricks that serve data. The per-volume auth.allow option defines which addresses or hostnames may receive that mount configuration, while auth.reject can deny specific sources even when a broader allow rule would otherwise match.

Access rules apply to new mount attempts, so existing mounted clients may stay connected until they unmount or reconnect. Check the source address the cluster actually sees when clients connect through NAT, VPN, or proxy paths, and use TLS identities with auth.ssl-allow when certificate-based client control is the intended boundary.

Steps to restrict GlusterFS client access:

List volumes from a trusted-pool node to confirm the target name.
```
$ sudo gluster volume list
volume1
volume2
```
Check the current allow rule before changing it.
```
$ sudo gluster volume get volume1 auth.allow
Option      Value
------      -----
auth.allow  *
```
* means new native clients are allowed unless another rule or network control blocks them.
Check for an existing reject rule that could override the allow rule.
```
$ sudo gluster volume get volume1 auth.reject
Option       Value
------       -----
auth.reject  none
```
auth.reject takes precedence over auth.allow, so a rejected client remains blocked even if its network appears in the allowlist.
Set the auth.allow allowlist for the volume.
```
$ sudo gluster volume set volume1 auth.allow 10.0.0.0/24,10.0.0.21
volume set: success
```
A wrong auth.allow value can block new client mounts until it is corrected from a trusted-pool node. Separate multiple entries with commas and no spaces, and prefer IP addresses or CIDR ranges when DNS consistency across storage nodes is uncertain.
Verify the stored allowlist value.
```
$ sudo gluster volume get volume1 auth.allow
Option      Value
------      -----
auth.allow  10.0.0.0/24,10.0.0.21
```
Reset the allow rule with sudo gluster volume reset volume1 auth.allow when the volume should return to its default access behavior.
Mount the volume from an approved client.
```
$ sudo mount -t glusterfs node1:/volume1 /mnt/volume1
```
Related: How to mount a GlusterFS volume in Linux

Confirm the approved client has an active mount.

$ df -h /mnt/volume1
Filesystem      Size  Used Avail Use% Mounted on
node1:/volume1  1.0T  120G  880G  13% /mnt/volume1

Attempt the same mount from an unapproved client.

$ sudo mount -t glusterfs node1:/volume1 /mnt/volume1
mount.glusterfs: failed to fetch volume file (Permission denied)
mount: /mnt/volume1: mount(2) system call failed: Permission denied.

Denied native mount attempts are also visible in GlusterFS logs under /var/log/glusterfs.

Related: How to check GlusterFS logs

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.