> Source: [sk184812](https://support.checkpoint.com/results/sk/sk184812)

# sk184812 - Maestro Security Group Members appear as "Detached" and Site 2 is not detected

| Property | Value |
|----------|-------|
| Solution ID | sk184812 |
| Date Created | 2026-04-30 |
| Last Modified | 2026-05-06 |
| Technical Level | Advanced |
| Products | Scalable Platforms |
| Versions | R82.10, R82, R81.20 |
| OS | Gaia |

## Symptoms

- * Maestro Security Group is configured in the Traditional VSX mode and is deployed in Dual Site.

* Output of the command "`cpstat ha -f all`" on some Security Group Members shows:

  ```
  
  Product name:    High Availability
  Major version:    XXX
  Minor version:    XXX
  Service pack:    XXX
  Version string:   N/A
  Status code:     2
  Status short:    Problem
  Status long:     Refer to the Notification and Interfaces tables for information about the problem
  HA installed:    1
  Working mode:    Unknown
  HA protocol version: 2
  HA started:     yes
  HA state:      down
  HA identifier:    2
  ...
  Problem Notification table
  ---------------------------------------------
  |Name       |Status |Priority|Verified|Descr|
  ---------------------------------------------
  ...
  |VSX        |OK     |       0|     XXX|     |
  |VSX Config |problem|       0|     XXX|     |
  ...
  ---------------------------------------------
  ```

* Output of the command "`asg monitor`" on Site 1 shows some Security Group Members on Site 2 as "`Detached`".

* Output of the command "`cphaprob stat`" on Site 1 shows the same problematic Security Group Members on Site 2 as "`Lost`".

* Removing and re-adding the problematic Security Group Members in the Orchestrator does not resolve the issue.

* Policy installation to non-SMO Virtual Systems fails with license-related errors.

* Additional troubleshooting shows that on the problematic Security Group Members, the file "`local.vsall`" is missing (it contains the local VSX configuration mapping).

* Additional troubleshooting shows that on the Security Group, the "`smartd`" daemon is stuck.

  It is blocked while executing the service "`start_linker start`".

  The script "`start_linker`" hangs because a required symbolic link to "`/usr/lib/smo/libappliance_api.sh`" is missing.

  This prevents the "`smartd`" daemon from completing its processing and blocks the Security Group database updates from the Orchestrator.

## Cause

The behavior is caused by a combination of Security Group metadata corruption on the SMO, a blocked orchestration daemon, missing VSX configuration files on several Security Group Members.

1. Invalid value of "ssm_groups_amount" in "smodb.json"

   * The SMO Security Group Member stores the internal Maestro Security Group metadata in an internal database file (`smodb.json`), including the number of Maestro Sites and the number of SSM groups (`ssm_groups_amount`).
   * In the affected environment, the SMO contained an invalid value in the `smodb.json` file:  
     The value of the parameter "`ssm_groups_amount`" was set to the string "`init`" instead of a numeric value ("`2`" for a Dual Site deployment).
2. "`smartd`" daemon is blocked by the missing symbolic link to "`libappliance_api.sh`"

   * On the SMO, the `smartd` daemon orchestrates Maestro operations, including:
     * Syncing Security Group metadata (`sgdb.json`) from the Orchestrator.
     * Updating Security Group mask and topology.
     * Handling some license updates for Security Group Members.
     * In this case, `smartd` was stuck while running the operation: `service start_linker start`
     * The "`start_linker`" script requires a symbolic link:  
       `/usr/lib/smo/libappliance_api.sh -> /usr/lib/appliances/common_tor/libappliance_api.sh`
     * This control plane blockage, combined with the incorrect "`ssm_groups_amount`" value, left the SMO with an outdated and inconsistent Security Group view even though data plane network connectivity between Orchestrators and Security Group Members was healthy.
3. VSX configuration inconsistency due to the missing "local.vsall" file

   * After Security Group Members were removed and re-added to the Security Group, some Security Group Members (1_02, 2_01, 2_02) did not have a valid "`local.vsall`" file.
   * VSX configuration did not converge until the "`local.vsall`" file was regenerated from the Security Management Server.

## Solution

This solution requires authentication. Please log in to view the full solution.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content