[Bug]: Serverinfo reports a stopped replica when no MariaDB replication is configured

[Franzz]

⚠️ This issue respects the following points: ⚠️

• This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
• This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
• I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
• I agree to follow Nextcloud's Code of Conduct.
• I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

Bug description

The Serverinfo → Database health check reports a replication warning on a MariaDB server where no replication is configured.

The warning displayed is:

A configured replica is not running.

with the justification:

Slave_running is reporting OFF.

This appears to be a false positive. On a MariaDB server without replication, Slave_running = OFF is expected.

There is no replica configuration in Nextcloud's config.php or in occ config:list system, and MariaDB reports no configured replica (SHOW REPLICA STATUS and SHOW ALL REPLICAS STATUS both return Empty set).

The warning appears to originate from apps/serverinfo/lib/Database/RuleSet/Mysql.php, where the Slave_lag rule tests Slave_running == 0 without apparently checking whether replication is actually configured.

Steps to reproduce

1. Run Nextcloud Server 35.0.0 with MariaDB 11.8.9.
2. Use a single MariaDB server with no replication configured.
3. Ensure MariaDB binary logging/replication is not configured (log_bin = OFF).
4. Open Administration → Serverinfo → Database.
5. Check the Replication section.

The MariaDB server reports:

SHOW REPLICA STATUS\G
Empty set

and:

SHOW ALL REPLICAS STATUS\G
Empty set

Slave_running reports OFF, as expected for a server without replication.

Expected behavior

If no database replication is configured, the Serverinfo health check should not report:

A configured replica is not running.

The replication check should either be skipped or considered not applicable when no replica is configured.

If replication is configured and the replica is not running, the warning should still be reported.

Nextcloud Server version

35

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 31 to 32)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

[stevefalco]

I am seeing the same failure indication on a stand-alone server. It does indeed look like a false positive to me.

[sahsanu]

Same issue here, until this is fixed upstream, I've edited apps/serverinfo/lib/Database/RuleSet/Mysql.php and commented out this code:

Before:

              $rules[] = new Rule(
                      id: 'Slave_lag',
                      name: 'Replica lag',
                      category: 'Replication',
                      severity: Rule::SEVERITY_ALERT,
                      formula: 'Slave_running',
                      test: 'value == 0',
                      issue: 'A configured replica is not running.',
                      recommendation: 'Check the replica with SHOW REPLICA STATUS; resolve any IO/SQL errors and restart replication.',
                      justification: 'Slave_running is reporting OFF.',
                      justificationFormula: '',
                      requires: ['Slave_running'],
              );

After:

//              $rules[] = new Rule(
//                      id: 'Slave_lag',
//                      name: 'Replica lag',
//                      category: 'Replication',
//                      severity: Rule::SEVERITY_ALERT,
//                      formula: 'Slave_running',
//                      test: 'value == 0',
//                      issue: 'A configured replica is not running.',
//                      recommendation: 'Check the replica with SHOW REPLICA STATUS; resolve any IO/SQL errors and restart replication.',
//                      justification: 'Slave_running is reporting OFF.',
//                      justificationFormula: '',
//                      requires: ['Slave_running'],
//              );

[superspeed500]

Same issue experienced in my home network when using a MariaDB cluster of three nodes with Nextcloud using a VIP as the communication towards the cluster. show replica status returns an empty set for my cluster, just as OP describes for a single-node system. I agree that this looks like a false positive.

[Bad-and-Mad]

dirty hack:

apps/serverinfo/lib/Database/RuleSet/Mysql.php

test: 'value == 999',

// ── Replication ─────────────────────────────────────────────

                $rules[] = new Rule(
                        id: 'Slave_lag',
                        name: 'Replica lag',
                        category: 'Replication',
                        severity: Rule::SEVERITY_ALERT,
                        formula: 'Slave_running',
                        test: 'value == 999',
                        issue: 'A configured replica is not running.',
                        recommendation: 'Check the replica with SHOW REPLICA STATUS; resolve any IO/SQL errors and restart replication.',
                        justification: 'Slave_running is reporting OFF.',
                        justificationFormula: '',
                        requires: ['Slave_running'],
                );

Unfortunately, Nextcloud's management has shifted very strongly toward “enterprise marketing” in recent years. They are determined to prove that they can keep up with the tech giants in terms of functionality, and in doing so, they often forget their core target audience: the admins who keep the system running.