One silly question: Did you try adding some files on the source volume after the georep was created ?<div><br></div><div>Can you share the output of your version of  '<span style="white-space-collapse: preserve;">sh -x /usr/libexec/glusterfs/gverify.sh masterVol slaveUser slaveHost slaveVol sshPort logFileName' check ?</span><br><br><div id="ymail_android_signature">Best Regards,<br>Strahil Nikolov</div> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Fri, Aug 30, 2024 at 23:29, Karl Kleinpaste</div><div><karl@kleinpaste.org> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> <div id="yiv0017088670"><div>
    <div class="yiv0017088670moz-cite-prefix">On 8/30/24 04:17, Strahil Nikolov
      wrote:<br clear="none">
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">Have you done the following
          setup on the receiving gluster volume:<br clear="none">
        </div>
      </div>
    </blockquote>
    <br clear="none">
    <font face="FreeSerif">Yes. For completeness' sake:</font><br clear="none">
    <font face="monospace">grep geoacct /etc/passwd /etc/group<br clear="none">
      /etc/passwd:geoacct:x:5273:5273:gluster
      geo-replication:/var/lib/glusterd/geoacct:/bin/bash<br clear="none">
      /etc/group:geoacct:x:5273:</font><br clear="none">
    <font face="monospace"><br clear="none">
      gluster-mountbroker status<br clear="none">
+-----------+-------------+---------------------------+-------------+----------------+<br clear="none">
      |    NODE   | NODE STATUS |         MOUNT ROOT        |   
      GROUP    |     USERS      |<br clear="none">
+-----------+-------------+---------------------------+-------------+----------------+<br clear="none">
      |    pms    |          UP | /var/mountbroker-root(OK) |
      geoacct(OK) | geoacct(j, n)  |<br clear="none">
      | localhost |          UP | /var/mountbroker-root(OK) |
      geoacct(OK) | geoacct(n, j)  |<br clear="none">
+-----------+-------------+---------------------------+-------------+----------------+</font><br clear="none">
    <font face="FreeSerif"><br clear="none">
      restarted glusterd<br clear="none">
      ssh-keyed, no-password access established.<br clear="none">
    </font><font face="monospace">gluster system:: execute gsec_create</font><font face="FreeSerif"><br clear="none">
      reports success, and
      /var/lib/glusterd/geo-replication/common_secret.pem.pub exists on
      both systems, containing 4 lines.<br clear="none">
      created geo-rep session, and configured ssh-port, as before,
      successful.<br clear="none">
      Issued start command. Status report still says </font><font face="monospace">Created</font><font face="FreeSerif">.<br clear="none">
      <br clear="none">
    </font><font face="monospace">PRIMARY NODE    PRIMARY VOL    PRIMARY
      BRICK    SECONDARY USER    SECONDARY         SECONDARY NODE   
      STATUS     CRAWL STATUS    LAST_SYNCED          <br clear="none">
-------------------------------------------------------------------------------------------------------------------------------------------<br clear="none">
      pjs           j              /xx/brick/j      geoacct          
      geoacct@pms::n    N/A               Created    N/A             N/A</font><br clear="none">
    <br clear="none">
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">Also, I think the source node
          must be able to reach the gluster slave. Try to mount the
          slave vol on the master via the fuse client in order to verify
          the status.</div>
      </div>
    </blockquote>
    <font face="FreeSerif"><br clear="none">
      Each has mounted the other's volume. A single file,
      /gluster/j/stuff, is seen by both and is not replicated into
      /gluster/n.<div id="yiv0017088670yqtfd75320" class="yiv0017088670yqt6937760078"><br clear="none">
      <br clear="none">
    </div></font><div id="yiv0017088670yqtfd86299" class="yiv0017088670yqt6937760078">
    </div><blockquote type="cite"><div id="yiv0017088670yqtfd56059" class="yiv0017088670yqt6937760078">
      </div><div dir="ltr"><div id="yiv0017088670yqtfd27481" class="yiv0017088670yqt6937760078">
        <div>Also, check with the following command (found it in <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://access.redhat.com/solutions/2616791" class="yiv0017088670">https://access.redhat.com/solutions/2616791
            )</a>:</div>
        <span>
          </span><pre><code>sh -x /usr/libexec/glusterfs/gverify.sh masterVol slaveUser slaveHost slaveVol sshPort logFileName</code></pre></div>
        </div>
    </blockquote>
    <font face="FreeSerif"><br clear="none">
      That must be the wrong URL, "libexec" doesn't appear there.<br clear="none">
      However, running it with locally-appropriate args:<br clear="none">
    </font><font face="monospace">/usr/libexec/glusterfs/gverify.sh j
      geoacct pms n 6427 /tmp/verify.log</font><font face="FreeSerif"><br clear="none">
      ...generates a great deal of regular logging output, logs nothing
      in /tmp/verify.log, but the shell execution trace made this
      complaint:<br clear="none">
    </font><font face="monospace">shell-init: error retrieving current
      directory: getcwd: cannot access parent directories: No such file
      or directory</font><font face="FreeSerif"><br clear="none">
      So I went looking for directories that might be restricted (it
      didn't tell me which one it didn't like), thus:<br clear="none">
    </font><font face="monospace">ls -ld / /gluster /gluster/? /xx
      /xx/brick /xx/brick/j<br clear="none">
      find /var/lib/glu* -type d | xargs ls -ld</font><font face="FreeSerif"><br clear="none">
      The only directory, on both systems, that was at all restricted
      was /var/lib/glusterd/geo-replication, so...<br clear="none">
    </font><font face="monospace">chmod ugo+rx
      /var/lib/glusterd/geo-replication</font><font face="FreeSerif"><br clear="none">
      ...to take care of that. Again, attempted start, to no effect, the
      session remains in Created state.<br clear="none">
      <br clear="none">
      I wish there was a single, exhaustive description of "problems
      causing georep not to initiate."<br clear="none">
      The fact that it reports apparent success without moving forward
      to Active state is odd, and maddening.<br clear="none">
      What event or state is which part of the process waiting for?
      Having started (in principle), what is evaluating conditions for
      moving to Active?</font><div id="yiv0017088670yqtfd02766" class="yiv0017088670yqt6937760078"><br clear="none">
  </div></div></div> </div> </blockquote></div>