How to generate a support package

Linux deployment

Run the following command:

In case of a successful generation, you should see the following message:

Windows deployment

Before you begin, please run the following command in an elevated PowerShell to allow the utility script (mdss.ps1) to be executed

In order to generate a support package please run the following commands in the scripts folder within the installation folder (by default C:\Program Files\OPSWAT\MetaDefender Storage Security\scripts)

In case of a successful generation, you should see the following message:

For Kubernetes Deployment

In case of issues that require further investigation by OPSWAT support, a package can be generated using the sp.sh script what contains pod logs, configurations and details regarding the Kubernetes deployment. In order to generate the support package, make the sp.sh script executable and run the following command:

./sp.sh <NAMESPACE>

Notes:

• The namespace name where the application is deployed needs to be specified as an argument, otherwise the default namespace is used.

• The script uses kubectl to extract the required information, make sure kubectl is installed and configured with the correct context.

• The script generates the support package as a zip file in the same directory where it is executed.

Maximum limit

The package can grow very large on systems with extensive logs. In order to prevent this, you can use the -m / --max-size argument as such:

Linux

Windows

How the size budget is allocated internally

When -m is provided, the total budget is split into two parts:

1. Settings/host info reservation — 50MB reserved for non-log data (settings, host info, env files). Configurable via env var RESERVED_FOR_SETTINGS.

2. Logs budget = max_size - 50MB — everything remaining goes to logs.

The logs budget itself is then divided into:

• Container logs — each container is capped at the last 25,000 lines (configurable via CONTAINER_LOG_LINES)

• Script logs — always included in full (usually small)

• Service logs — whatever budget remains after container + script logs

How service logs are collected (the two-phase approach)

Phase 1 — Fair representation: Takes the N most recent log files from each service (default: 1 file, configurable via MIN_FILES_PER_SERVICE). This guarantees every service has at least some representation in the package, even if the budget is tight. Phase 2 — Fill remaining budget: Any budget left after Phase 1 is filled with the most recently modified log files across all services, globally sorted by timestamp — most recent first.Files are never arbitrarily truncated — they are only truncated if they exceed the remaining budget, and when truncated, the last N bytes are kept (most recent content) via tail -c.

Environment variable overrides