How to check GlusterFS logs

When a GlusterFS volume looks healthy in status output but clients still report disconnects, heal stalls, or I/O errors, the node-local logs usually contain the first useful failure signal. Checking the right management, brick, and helper logs keeps the investigation tied to the node and time window where the problem happened.

GlusterFS stores server logs under /var/log/glusterfs. The management daemon writes /var/log/glusterfs/glusterd.log, CLI activity appears in cli.log and cmd_history.log, brick logs live under /var/log/glusterfs/bricks with filenames derived from brick paths, and heal or rebalance work writes separate logs such as glustershd.log or <volume>-rebalance.log.

Run these checks on the node that owns the affected brick, plus any client that shows mount errors when client-side behavior is part of the incident. Log files may rotate before the investigation starts, so search a specific symptom across current and rotated files rather than assuming the newest log contains the failure.

1. Confirm the affected volume and brick path.

   $ sudo gluster volume status volume1
   Status of volume: volume1
   Gluster process                             TCP Port  RDMA Port  Online  Pid
   ------------------------------------------------------------------------------
   Brick node1:/srv/gluster/brick1             49152     0          Y       2143
   Brick node2:/srv/gluster/brick1             49152     0          Y       2311
   Self-heal Daemon on node1                   N/A       N/A        Y       2202
   Self-heal Daemon on node2                   N/A       N/A        Y       2370

   Replace volume1 with the volume name under investigation. The brick host and path determine which server node and brick log to inspect first.
   Related: How to check GlusterFS volume status

2. List the top-level GlusterFS log files on that node.

   $ sudo ls /var/log/glusterfs
   bricks
   cli.log
   cmd_history.log
   glusterd.log
   glustershd.log
   volume1-rebalance.log

3. Search the management daemon log for a peer or service symptom.

   $ sudo zgrep --fixed-strings "Transport endpoint is not connected" /var/log/glusterfs/glusterd.log*
   [2026-06-16 09:24:18.124512 +0000] E [MSGID: 106005] [glusterd-handler.c:558:__glusterd_handle_cli_get_volume] 0-management: Transport endpoint is not connected for brick node2:/srv/gluster/brick1

   zgrep searches plain and compressed rotated logs with the same command. Use a symptom string from the failed command, client error, or incident alert instead of scanning for every warning level.

4. Check CLI history for administrative changes near the incident.

   $ sudo grep --fixed-strings "volume set" /var/log/glusterfs/cmd_history.log
   2026-06-16 09:22:03 : volume set volume1 performance.write-behind off

   Use /var/log/glusterfs/cli.log for CLI-side errors and cmd_history.log for the command timeline.

5. List brick log files on the server that owns the affected brick.

   $ sudo ls /var/log/glusterfs/bricks
   srv-gluster-brick1.log
   srv-gluster-brick2.log

   Brick log filenames commonly mirror the brick path with / characters converted into hyphens.

6. Search the affected brick log for the storage or network error.

   $ sudo grep --fixed-strings "Input/output error" /var/log/glusterfs/bricks/srv-gluster-brick1.log
   [2026-06-16 09:24:18.122041 +0000] E [MSGID: 113007] [posix.c:3312:posix_writev] 0-volume1-posix: writev failed on /srv/gluster/brick1: Input/output error

   Search for the exact client or kernel error first, such as Input/output error, Transport endpoint is not connected, or the affected file path.

7. Check the self-heal daemon log when the volume has pending heal entries.

   $ sudo grep --fixed-strings "completed selfheal" /var/log/glusterfs/glustershd.log
   [2026-06-16 09:30:44.312008 +0000] I [MSGID: 108026] [afr-self-heal-common.c:1855:afr_log_selfheal] 0-volume1-replicate-0: completed selfheal for /reports/q2.csv

   Use the heal commands to confirm whether the backlog is shrinking after reviewing the daemon log.
   Related: How to heal a GlusterFS volume

8. Check the rebalance log after a rebalance run.

   $ sudo grep --fixed-strings "status=completed" /var/log/glusterfs/volume1-rebalance.log
   [2026-06-16 10:02:11.003881 +0000] I [MSGID: 109036] [rebalance.c:610:gf_defrag_status_get] 0-volume1-rebalance: status=completed files=182 scanned=182 failures=0

   Replace volume1 with the volume name. Rebalance logs are per volume and commonly use the <volume>-rebalance.log filename.
   Related: How to rebalance a GlusterFS volume

9. Check the client mount log when only one client reports the failure.

   $ sudo grep --fixed-strings "Transport endpoint is not connected" /var/log/glusterfs/mnt-volume1.log
   [2026-06-16 09:24:18.126004 +0000] W [MSGID: 114031] [client-rpc-fops_v2.c:2665:client4_0_lookup_cbk] 0-volume1-client-1: remote operation failed: Transport endpoint is not connected

   FUSE client logs are also under /var/log/glusterfs, and the filename is usually derived from the mount point path.