Shared Channel Invites Fail on Non-Leader Nodes in a High Availability Cluster

Applies to: Mattermost Server versions prior to v11.7.0, High Availability (multi-node) deployments with Connected Workspaces / Shared Channels enabled

Symptoms: Inviting a remote connection to a shared channel fails with a connection error when the request is handled by a non-leader node in the cluster.

🛑 Problem

In a High Availability (HA) cluster running a version prior to v11.7.0, the background workers responsible for delivering Connected Workspaces (Shared Channels) messages only run on the node that is the current cluster leader. When a share or invite request is handled by a non-leader node, the request is accepted but the outbound message is never delivered, because no worker on that node processes it. Because a load balancer distributes requests across all nodes, this produces intermittent share/invite failures depending on which node handles a given request, even though your configuration is correct and identical across all nodes.

Symptoms

error="getSharedChannelsService: Shared Channels Service is disabled."

The System Console Select channels dialog shows:

<channel-name> could not be added to this connection.

Additional symptoms:

• ConnectedWorkspacesSettings.EnableSharedChannels and EnableRemoteClusterService are true and identical on every node, ruling out a configuration mismatch.
• GET /api/v4/remotecluster/{remote_id}/sharedchannelremotes returns 200, but POST .../channels/{channel_id}/invite returns 400 on the affected node.
• Restarting only the affected node does not resolve the issue, because it rejoins the cluster as a follower and the delivery workers still do not run on it.
• The failure is not related to the channel's Public/Private setting; it is a service-availability issue.

✅ Solution

This issue is fixed in Mattermost Server v11.7.0 (Extended Support Release) and later. Upgrading is the permanent resolution. If you cannot upgrade immediately, route Connected Workspaces administration to the current cluster leader as an interim workaround.

Upgrade to a Fixed Release

Upgrade to v11.7 ESR or later. This release starts the message-delivery workers on all cluster nodes instead of only the leader, so share/invite requests succeed regardless of which node handles them.

⚠️ Important: Follow your standard upgrade procedure and test in a staging environment first. See the upgrade guide linked below.

Interim Workaround: Route to the Cluster Leader

Until you upgrade, identify the affected node and route Connected Workspaces operations around it.

Compare mattermost.log across nodes for the following error, logged only on the node where the workers failed to start:

Error starting inter-cluster services

Shared Channel Service cannot activate: requires Remote Cluster Service

Alternatively, attempt the share/invite action against each node's own address (not the load balancer's virtual IP). The node that succeeds currently holds the cluster leadership.

Perform channel-sharing actions (System Console Connected Workspaces, or the invite dialog) against the leader node's direct address instead of the load balancer VIP.

POST /api/v4/remotecluster/{remote_id}/channels/{channel_id}/invite

Additional Resources

For more information, see:

Upgrading Mattermost Server

Connected Workspaces

Generating a Support Packet