GlusterFS on AlmaLinux 9 and Rocky 9: a three-node replicated volume

Updated October 2026 for AlmaLinux 9 and Rocky Linux 9.

GlusterFS pools a disk from each of several Linux servers into one replicated volume, so a node can go down for patching or a dead drive and clients keep reading and writing. This guide builds the smallest setup worth running: three nodes on AlmaLinux 9 or Rocky Linux 9, with two data copies and an arbiter. Read the project status section before you commit to it, because Gluster in 2026 isn’t the safe default it was when this post first went up.

I’ve used Gluster for VM storage in Proxmox and as a highly available SMB file server for Windows clients. It works. Whether you should start something new on it is a different question.

Where GlusterFS stands in 2026

Short version: it still runs, but it’s in slow maintenance, and the big platforms have walked away.

• Red Hat ended its commercial product. Its Gluster Storage life cycle page says support ran through 31 December 2024, with RHGS 3.5 as the final series.
• Upstream releases have slowed to a trickle. GlusterFS 11.0 shipped in February 2023, 11.1 in November 2023 and 11.2 in July 2025 (release history). There’s no version 12. The CentOS Storage SIG packages for EL9 still stop at 11.1.
• Proxmox VE 9.0 (August 2025) removed its GlusterFS storage type. The Proxmox roadmap gives the reason plainly: “As GlusterFS is no longer maintained upstream, Proxmox VE 9 drops support for GlusterFS storages.”
• The remaining maintainers say the project is alive but quieter. In the GitHub thread “Is the project still alive?”, one of them put it as “going through a slow period because Red Hat is stopping Gluster based product. But the project is living on.”

My take: if you already run Gluster and it’s stable, there’s no fire. Keep it patched and plan the next move. For a new VM storage cluster, I’d pick Ceph.

When Ceph is the better choice

Gluster is still a reasonable fit for one job: a POSIX file share across three boxes, run by a small team that wants something simple. Ceph wins almost everywhere else.

If you need S3-style object storage and nothing else, MinIO is simpler than either. GigeNET builds dedicated storage servers for Ceph and MinIO, with a 10 Gbps private network between nodes for $20 a month per server. For a hosted multi-server build, see our server clusters.

Full replica or arbiter?

Gluster keeps writes consistent with quorum. With three nodes, two must be up to accept writes. Two-node clusters are possible but risk split-brain, where each node holds a different version of the same file. Don’t run production that way.

You have two three-node layouts:

1. Replica 3. Every file lives on all three nodes. Highest availability, and it costs three times the raw space.
2. Replica 2 plus an arbiter. Two nodes hold the data. The third holds only file names and metadata, so it still votes in quorum but needs a fraction of the disk. Gluster’s arbiter docs suggest about 4 KB of arbiter space per file. The trade-off is that your data exists on two nodes, not three.

This guide builds the arbiter layout, since it has a couple of extra details. The replica 3 command is at the end of the volume section.

What you need

Three physical servers or VMs running AlmaLinux 9 or Rocky Linux 9. If they’re VMs, put them on separate hosts, or one host failure takes out the whole cluster. My lab used 2 cores, 1 GB RAM and a 20 GB OS disk each, which is fine for testing and nowhere near enough for real load.

Each node needs a second disk for the Gluster brick. I gave gluster1 and gluster2 80 GB each and gluster3, the arbiter, 10 GB. Put all three on the same private subnet:

gluster1  10.255.255.21
gluster2  10.255.255.22
gluster3  10.255.255.23

All nodes: hostnames

Set each hostname, then add all three to /etc/hosts so Gluster doesn’t depend on DNS being reachable:

hostnamectl set-hostname gluster1    # gluster2 / gluster3 on the others

cat >> /etc/hosts <<'EOF'
10.255.255.21  gluster1
10.255.255.22  gluster2
10.255.255.23  gluster3
EOF

All nodes: prepare the brick disk

A brick is a directory on a local filesystem that Gluster uses as one member of a volume. Think of it as one disk in a network RAID set. Check the new disk’s name first; it may be sdb, vdb or nvme1n1 depending on the hardware.

lsblk
parted -s /dev/sdb mklabel gpt mkpart gluster xfs 0% 100%
mkfs.xfs -i size=512 /dev/sdb1
mkdir -p /data/brick1
echo "UUID=$(blkid -s UUID -o value /dev/sdb1) /data/brick1 xfs defaults 0 0" >> /etc/fstab
systemctl daemon-reload
mount -a
df -h /data/brick1

The -i size=512 inode size comes from Gluster’s quick start guide; Gluster stores its metadata in extended attributes, and larger inodes keep them inline. You should see /dev/sdb1 mounted on /data/brick1 on all three nodes.

All nodes: install GlusterFS and open the firewall

Packages come from the CentOS Storage SIG. AlmaLinux 9 and Rocky Linux 9 both carry the repo setup package in their Extras repository, which is enabled by default. centos-release-gluster11 is the newest one; gluster9 and gluster10 are older.

dnf install -y centos-release-gluster11
dnf install -y glusterfs-server
systemctl enable --now glusterd

The old version of this post told you to disable SELinux and firewalld. Don’t. glusterfs-server pulls in the glusterfs-selinux policy package and ships a firewalld service called glusterfs, which opens the management ports (24007–24008), the brick range (49152–60999) and the Gluster NFS ports. Out of the box, any host that can reach those ports can mount the volume. No password is involved, so limit them to your private subnet:

firewall-cmd --permanent --zone=internal --add-source=10.255.255.0/24
firewall-cmd --permanent --zone=internal --add-service=glusterfs
firewall-cmd --reload

On gluster1: build the pool and the volume

Link the nodes together. Use hostnames, not IPs:

gluster peer probe gluster2
gluster peer probe gluster3
gluster peer status

Both peers should show State: Peer in Cluster (Connected). Now create the volume:

gluster volume create stor1 replica 2 arbiter 1 \
  gluster1:/data/brick1/stor1 \
  gluster2:/data/brick1/stor1 \
  gluster3:/data/brick1/stor1
gluster volume start stor1
gluster volume info stor1

• stor1 is the volume name.
• replica 2 arbiter 1 means two data bricks plus one arbiter. The last brick in each set of three becomes the arbiter. You’ll still see the older spelling, replica 3 arbiter 1, in many guides; Gluster accepts both and they build the same thing.
• The brick path is a subdirectory of the mount, not /data/brick1 itself. Gluster refuses a brick at the root of a mount point unless you force it, and the subdirectory protects you from writing into the OS disk if the brick filesystem ever fails to mount.

In the volume info output, look for Number of Bricks: 1 x (2 + 1) = 3 and (arbiter) after the gluster3 brick. If you want full three-way replication instead, drop the arbiter: gluster volume create stor1 replica 3 with the same three bricks.

Mount the volume on a client

On an EL9 client, install the FUSE client from the same SIG repo. On Debian or Ubuntu the package is glusterfs-client. The client also needs the three hostnames in /etc/hosts or DNS.

# AlmaLinux / Rocky 9
dnf install -y centos-release-gluster11
dnf install -y glusterfs-fuse

# Debian / Ubuntu
apt install glusterfs-client

mkdir -p /mnt/stor1
mount -t glusterfs -o backup-volfile-servers=gluster2:gluster3 gluster1:/stor1 /mnt/stor1

The server named in the mount command is only used to fetch the volume layout; after that the client talks to every brick directly. backup-volfile-servers (colon-separated) lets the mount still succeed at boot if gluster1 happens to be down. To make it permanent, add this to /etc/fstab:

gluster1:/stor1  /mnt/stor1  glusterfs  defaults,_netdev,backup-volfile-servers=gluster2:gluster3  0 0

_netdev tells systemd to wait for the network before mounting.

Proxmox VE 9

The old Datacenter > Storage > Add > GlusterFS screen is gone in Proxmox VE 9. Proxmox’s own advice is to mount the volume yourself and add it as directory storage. On every Proxmox node, add the Gluster hostnames to /etc/hosts, install glusterfs-client (Debian 13 ships 11.1), and mount the volume at the same path with the fstab line above, using /mnt/gluster-stor1 as the mount point. Then, once, from any node:

pvesm add dir gluster-stor1 --path /mnt/gluster-stor1 \
  --content images,iso,backup --shared 1 --is_mountpoint yes

--shared 1 tells Proxmox every node sees the same files, so live migration works. --is_mountpoint yes marks the storage offline if the mount is missing, instead of letting Proxmox write VM disks onto the local root disk. In my lab this gave 80 GB of replicated space for VM disks, ISO images and backups.

It works, but you’re now running VM disks over a FUSE mount on a storage plugin the hypervisor vendor dropped. For a new Proxmox cluster, use the built-in Ceph instead.

Sizing it for real

On physical nodes, Gluster gets faster and more resilient with SSD or NVMe bricks and a dedicated 10 Gbps back-end network, because every write goes to each replica before it’s acknowledged. Keep storage traffic off the public interface.

If you’d rather not run the storage layer yourself, look at GigeNET’s managed services, or tell us what you’re building and we’ll quote a Ceph or MinIO cluster.