Explain the removed COORDINATOR privilege where readers hit it

pages/database-management/authentication-and-authorization/query-privileges.mdx

@@ -211,21 +211,22 @@ coordinator with basic auth carries both implicitly.
 | `SHOW INSTANCE` / `SHOW INSTANCES` | `COORDINATOR_READ` | `SHOW INSTANCES` |
 | `SHOW COORDINATOR SETTINGS` | `COORDINATOR_READ` | `SHOW COORDINATOR SETTINGS` |
 | `SHOW REPLICATION LAG` | `COORDINATOR_READ` | `SHOW REPLICATION LAG` |
+| `SHOW ROUTING TABLE` | `COORDINATOR_READ` | `SHOW ROUTING TABLE` |
 | `SHOW ROLES` / `SHOW PRIVILEGES FOR ROLE` | `COORDINATOR_READ` | `SHOW PRIVILEGES FOR ROLE dba` |
 | `SHOW CONFIG`, `SHOW SETTING`, system info queries | `COORDINATOR_READ` | `SHOW CONFIG` |
 | `SHOW VERSION` | `COORDINATOR_READ` | `SHOW VERSION` |
 | `SHOW CURRENT USER` / `SHOW CURRENT ROLE` | **None** | Self-service identity queries. |
 | Cluster management operations | `COORDINATOR_WRITE` | `REGISTER INSTANCE`, `SET INSTANCE ... TO MAIN`, `ADD COORDINATOR`, `YIELD LEADERSHIP`, `FORCE RESET CLUSTER STATE`, … |
 | `SET COORDINATOR SETTING` / `SET SETTING` | `COORDINATOR_WRITE` | `SET COORDINATOR SETTING 'sync_failover_only' TO 'true'` |
 | `CREATE ROLE` / `DROP ROLE` / `GRANT` / `REVOKE` | `COORDINATOR_WRITE` | `GRANT COORDINATOR_READ TO analyst` |
-| `COORDINATOR` operations | `COORDINATOR` | Various coordinator commands. |
-| `SHOW COORDINATOR SETTINGS` | `COORDINATOR` | `SHOW COORDINATOR SETTINGS` |
-| `SHOW ROUTING TABLE` | `COORDINATOR` | `SHOW ROUTING TABLE` |
 
 <Callout type="warning">
-**Breaking change in Memgraph 3.13:** the `COORDINATOR` privilege was removed
-and replaced by `COORDINATOR_READ` and `COORDINATOR_WRITE`. It never gated any
-operation and is no longer accepted in `GRANT` / `DENY` / `REVOKE` statements.
+**Breaking change in Memgraph 3.13:** the `COORDINATOR` privilege was removed.
+It never gated any operation. `GRANT`, `DENY` and `REVOKE` statements that name
+it fail with a [syntax error](/help-center/errors/auth#error-5), and `SHOW
+PRIVILEGES` and `GRANT ALL PRIVILEGES` no longer include it. `COORDINATOR_READ`
+and `COORDINATOR_WRITE` don't replace it: they apply only on coordinators, and
+data instances reject them.
 </Callout>
 
 ## Schema information

pages/database-management/authentication-and-authorization/role-based-access-control.mdx

@@ -258,14 +258,15 @@ For a comprehensive reference of which privileges are required for specific quer
 
 <Callout type="warning">
 **Breaking change in Memgraph 3.13:** the `COORDINATOR` privilege was removed —
-it never gated any operation. It is no longer accepted in `GRANT` / `DENY` /
-`REVOKE` statements and is no longer reported by `SHOW PRIVILEGES`. A stale
+it never gated any operation. `GRANT`, `DENY` and `REVOKE` statements that name
+it fail with a [syntax error](/help-center/errors/auth#error-5), and it is no
+longer reported by `SHOW PRIVILEGES`. A stale
 `COORDINATOR` grant in an existing deployment is never reported and never
 checked, so no migration is needed.
 
-Access to [high availability](/database-management/clustering/high-availability) coordinators is now
-controlled by the `COORDINATOR_READ` and `COORDINATOR_WRITE` privileges. These
-are **coordinator-only**: they are granted to roles that live on the
+Access to [high availability](/database-management/clustering/high-availability) coordinators is
+controlled by the `COORDINATOR_READ` and `COORDINATOR_WRITE` privileges, which
+aren't a replacement for `COORDINATOR`. These are **coordinator-only**: they are granted to roles that live on the
 coordinators themselves, they are not part of the data-instance privilege set,
 and `GRANT ALL PRIVILEGES` on a data instance does not grant them. See
 [coordinator

pages/database-management/clustering/high-availability/coordinator-authentication.mdx

@@ -52,12 +52,13 @@ after being down, and survive leader failover.
 
 <Callout type="warning">
 **Breaking change in Memgraph 3.13:** the `COORDINATOR` privilege has been
-removed. It never gated any operation. It is no longer accepted in `GRANT` /
-`DENY` / `REVOKE` statements and is no longer reported by `SHOW PRIVILEGES`. A
-stale `COORDINATOR` grant in an existing deployment is simply never reported and
-never checked — no migration is required. Coordinator access is now controlled
-by the new `COORDINATOR_READ` and `COORDINATOR_WRITE` privileges described
-below, which are granted **on the coordinators themselves**, not on data
+removed. It never gated any operation. `GRANT`, `DENY` and `REVOKE` statements
+that name it fail with a [syntax error](/help-center/errors/auth#error-5), and
+it is no longer reported by `SHOW PRIVILEGES`. A stale `COORDINATOR` grant in an
+existing deployment is simply never reported and never checked — no migration
+is required. The `COORDINATOR_READ` and `COORDINATOR_WRITE` privileges
+described below aren't a replacement for it: they control access to
+coordinators and are granted **on the coordinators themselves**, not on data
 instances.
 </Callout>
 

pages/database-management/upgrades/deprecated-features.mdx

@@ -1,12 +1,13 @@
 ---
 title: Deprecated features
-description: Configuration flags that are deprecated or removed in Memgraph, and the versions where each change happened.
+description: Configuration flags and privileges that are deprecated or removed in Memgraph, and the versions where each change happened.
 ---
 
 # Deprecated features
 
 This section lists the configuration flags which have been deprecated, removed
-or replaced in Memgraph, and the versions where the changes happened.
+or replaced in Memgraph, and the versions where the changes happened. For
+privileges, see [Removed privileges](#removed-privileges).
 
 Removing a flag is a three-part process:
 - From the **Deprecated in** version, the flag still works, but it is announced as going away.
@@ -32,3 +33,16 @@ Removing a flag is a three-part process:
 | `--auth-module-create-missing-role` | 2.15 | 2.15 | 2.18 | Handled by the [auth module](/database-management/authentication-and-authorization/auth-system-integrations#auth-module-architecture) itself. |
 | `--auth-module-manage-roles` | 2.15 | 2.15 | 2.18 | Handled by the [auth module](/database-management/authentication-and-authorization/auth-system-integrations#auth-module-architecture) itself. |
 | `--storage-recover-on-startup` | 2.11 | 2.18 | 2.18 | [`--data-recovery-on-startup`](/database-management/multi-tenancy#configuration-flags). |
+
+## Removed privileges
+
+| Privilege | Rejected from | Replacement |
+| --------- | ------------- | ----------- |
+| `COORDINATOR` | 3.13 | None |
+
+`COORDINATOR` never gated any operation. From 3.13, `GRANT`, `DENY` and
+`REVOKE` statements that name it fail with a [syntax
+error](/help-center/errors/auth#error-5), so remove them. A grant made before
+3.13 is never checked. Access to high availability coordinators is controlled
+by separate, coordinator-only privileges; see [coordinator
+authentication](/database-management/clustering/high-availability/coordinator-authentication).

pages/help-center/errors/auth.mdx

@@ -21,6 +21,8 @@ import {CommunityLinks} from '/components/social-card/CommunityLinks'
    memgr.ph/auth.](#error-1)
 7. [You are not authorized to execute this query on database "memgraph"!](#error-3)
 8. [In a multi-tenant environment, SHOW PRIVILEGES query requires database specification. Use ON MAIN, ON CURRENT or ON DATABASE db_name.](#error-4)
+9. [Error on line 1 position 7 with the COORDINATOR token. The underlying parsing error is no viable alternative at input 'GRANTCOORDINATOR'.](#error-5)
+10. [COORDINATOR_READ and COORDINATOR_WRITE are coordinator-only privileges and cannot be granted, denied, or revoked on a data instance.](#error-6)
 
 
 ## Couldn't authenticate user [#error-1]
@@ -94,4 +96,46 @@ This error typically occurs when:
 - For roles: Use `SHOW PRIVILEGES FOR role_name` without database specification
 - For users: Always specify the database context when working in multi-tenant environments to ensure you're viewing the correct privileges for the intended database
 
+## COORDINATOR privilege rejected [#error-5]
+
+Memgraph 3.13 removed the `COORDINATOR` privilege. It never gated any
+operation, so statements that name it fail with a syntax error:
+
+```cypher invalid
+GRANT COORDINATOR TO backup;
+```
+
+```plaintext copy=false
+Error on line 1 position 7 with the COORDINATOR token. The underlying parsing error is no viable alternative at input 'GRANTCOORDINATOR'. Take a look at clauses around and try to fix the query.
+```
+
+`DENY COORDINATOR` and `REVOKE COORDINATOR` fail the same way, with
+`DENYCOORDINATOR` or `REVOKECOORDINATOR` in the message.
+
+{<h3 className="custom-header">Solution</h3>}
+
+Remove these statements from provisioning scripts. A `COORDINATOR` grant made
+before 3.13 is never checked, so removing it changes no access. Grant the role
+the privileges its queries need instead; see [query
+privileges](/database-management/authentication-and-authorization/query-privileges).
+
+## Coordinator privilege on a data instance [#error-6]
+
+`COORDINATOR_READ` and `COORDINATOR_WRITE` control access to high availability
+coordinators, and only coordinators accept them. Granting, denying or revoking
+them on a data instance fails:
+
+```cypher invalid
+GRANT COORDINATOR_READ TO backup;
+```
+
+```plaintext copy=false
+COORDINATOR_READ and COORDINATOR_WRITE are coordinator-only privileges and cannot be granted, denied, or revoked on a data instance.
+```
+
+{<h3 className="custom-header">Solution</h3>}
+
+Run the statement on a coordinator, against a role that exists there. See
+[coordinator authentication](/database-management/clustering/high-availability/coordinator-authentication).
+
 <CommunityLinks/>