Install and deploy Sophos Protection for Linux

Important product boundary: Although the Sophos onboarding page calls this section Deployment to Linux within the Endpoint guide, its Linux links lead to Server Protection and Sophos Protection for Linux (SPL) in Sophos Fusion (formerly Sophos Central). Linux therefore does not use the Windows or macOS Endpoint installer described in the adjacent sections. It has its own Linux server agent, policies, requirements, release notes and installation procedures.

The overall process from tenant preparation to operations is set out in the Endpoint onboarding path. This article covers only its Linux server track.

For one Linux server, first choose the protection mode under My Environment > Installers: Download Linux Server Installer for full malware protection, or Download XDR Sensor Linux Server Installer for the XDR Sensor without its own malware protection. Make the SophosSetup.sh installer downloaded for the intended tenant and mode executable and run it with root privileges. For multiple systems, distribute that installer through a controlled software deployment process and run --test first. If SPL is to be included in a VM template, use the documented Linux gold-image process so that every clone receives its own device identity. Sophos recommends considering this approach for autoscaling, load-balancing and large VM environments.

Before the first pilot device

Approve installation only after checking the following points:

• Licence and required protection scope: Server Protection offers two separate Linux downloads. The XDR Sensor requires an XDR licence and, according to Sophos, does not protect against threats by itself; third-party protection must be present. Check the intended mode against the available licence before downloading.
• Supported platform: The distribution, version, architecture and kernel must match the current SPL support matrix. Sophos lists the currently tested platforms and system requirements in the release notes. Unlisted, hardened, minimal, customised or legacy variants have specific support limitations. Do not force SPL onto immutable distributions; Sophos directs those environments to the separate Sophos Linux Sensor.
• Base requirements: At the content review on 14 September 2026, the SPL release notes required 2.5 GB of free disk space, 2 GB of free memory, x86_64 or ARM64, a running supported systemd, Bash, and glibc 2.17 or later, or 2.18 or later on ARM64. ARM64 additionally required kernel 5.3 or later. The installer required curl; the AV plugin required setcap from libcap2-bin, libcap or libcap-progs. This dated baseline does not replace the current approval check.
• Network access: The device must be able to reach Sophos Fusion during and after installation. Test DNS, HTTPS, the proxy, TLS inspection and, where applicable, Message Relay and Update Cache from every intended server network according to the network and proxy requirements.
• Existing protection: Sophos Anti-Virus for Linux cannot run alongside SPL. Remove SAV first or migrate it by invoking the installer with --uninstall-sav. With an XDR Sensor-only deployment, third-party protection must remain active because the sensor does not provide malware protection. Before deploying full SPL malware protection, assess any proposed coexistence with other antivirus products separately against the vendors’ support statements.
• Rollout contract: Record the target population, Central group, product scope, pilot size, stop criteria, maintenance window and rollback path before starting.

Maintain release, platform and network information

This article is the internal review baseline for Linux-specific requirements. The responsible owner checks the current SPL release notes and the distribution and kernel support matrix in the Sophos portal monthly and before every pilot and rollout wave. Record the review date, reviewer, release level, distribution, version, architecture, kernel, minimum resources, deviations and approval decision in the change. If current information differs from the dated baseline above, update the pilot criteria and this article before the next wave; old values do not constitute approval.

The linked network guide owns the shared allowlist and proxy process, including Linux- and licence-dependent destinations. For software packages, staged updates, Update Cache and Message Relay, also follow Sophos Endpoint updates, cache and Message Relay. The Linux pilot must still validate the actual path and installed SPL version from every intended server network.

Check filesystems and resources first

Only for full malware protection with the antivirus product installed: SPL can reliably scan and quarantine files only on explicitly supported filesystems. At the source review on 20 September 2026, Sophos listed bfs, btrfs, cifs, devtmpfs, ecryptfs, ext2, ext3, ext4, fuse, fuseblk, iso9660, jfs, jfs2, msdos, nfs, nfs4, overlay, squashfs, tmpfs, udf, vfat, xfs and zfs. Recheck this list against the current SPL documentation before every wave. On the AV pilot device, list all mounted targets and types with:

findmnt -rn -o TARGET,FSTYPE

In AV mode, check not only / and the installation location, but every mount containing business data, containers, network shares or intended scan targets. An unlisted filesystem is not approved merely because an initial test appears to work. Sophos recommends excluding unsupported filesystems from scanning; the AV plugin automatically excludes filesystems with known issues and records the event in soapd.log. Scan targets, quarantine and this AV log are not acceptance criteria for an XDR Sensor-only deployment.

SPL manages CPU and memory limits through Linux cgroups. According to Sophos, the defaults work well for most environments, so do not add blanket limits before the pilot. If an operational requirement calls for limits, first measure the workload and application tolerance, then read the locally installed /opt/sophos-spl/base/etc/cgroup-resource-limits-README.txt. It is authoritative because options, components and valid values can change. Custom values belong in /opt/sophos-spl/base/etc/cgroup-limits.conf; CPU values are percentages of total CPU and require %, while memory values can be MB or percentages depending on the option. SPL rejects values outside a supported range and uses its default. This article therefore deliberately supplies no universal numbers.

After installation or a limit change, apply the following checks according to the mode actually installed:

1. Only with antivirus: findmnt reports a currently supported type for every intended scan target.
2. If cgroup limits were customised: /opt/sophos-spl/logs/base/watchdog.log confirms the configuration applied to the components actually installed and contains no configuration error.
3. If cgroup limits were customised: The system journal contains no process termination caused by the SPL cgroup. Not every Linux system retains journal data across a restart; configure persistent journal storage under the local operations policy if the event history must survive reboots.

Install a single server from Sophos Fusion

1. In Sophos Fusion, go to My Environment > Installers.
2. Under Server Protection, choose the appropriate Linux download: Download Linux Server Installer for full malware protection, or Download XDR Sensor Linux Server Installer for an XDR Sensor-only deployment (XDR licence and active third-party protection required). Do not use the Windows or macOS Endpoint installer. The separately offered Sophos Linux Sensor (SLS) is not the SPL XDR Sensor.
3. Transfer SophosSetup.sh to the intended Linux server through an access-controlled channel.
4. Change to the download directory and make the file executable:

chmod +x SophosSetup.sh

5. Run the pre-installation checks without installing anything:

sudo ./SophosSetup.sh --test

6. If the checks pass, start the installer:

sudo ./SophosSetup.sh

Without --install-dir, SPL installs in /opt/sophos-spl/. A successful shell process does not constitute rollout acceptance. Next, validate registration, the components actually installed, applicable policies and health in Central and locally. The AV checks below do not apply to an XDR Sensor-only deployment.

Download the installer directly on the server

For a manual download from the shell, copy the link address of the Linux installer chosen earlier (full protection or XDR Sensor) in Sophos Fusion and use it as the placeholder in the following commands:

wget '<LINUX-INSTALLER-LINK>' -O SophosSetup.sh
chmod +x SophosSetup.sh
sudo ./SophosSetup.sh --test
sudo ./SophosSetup.sh

Replace <LINUX-INSTALLER-LINK> with the address copied from your tenant for the chosen mode. Do not put the URL or downloaded file in public script repositories, tickets or publicly readable shares. For repeatable deployments, supply the installation artifact through the protected package or secret distribution mechanism of your platform.

Deploy to multiple Linux systems by script

Begin a mass rollout with a few representative servers. Include differences in distribution, kernel, architecture, hardening, proxy path, location, workload and existing security software in the pilot. Start the next bounded wave only after the pilot has passed acceptance.

The following script is an example only for full malware protection with additionally licensed XDR, not for an XDR Sensor-only deployment. It uses the Linux Server Installer downloaded for that mode, assigns the device to the LinuxServers\Pilot subgroup and requests the antivirus and xdr components:

#!/usr/bin/env bash
set -euo pipefail

if (( EUID != 0 )); then
  printf 'This rollout script must be run as root.\n' >&2
  exit 1
fi

installer='/var/tmp/SophosSetup.sh'
chmod 700 "$installer"

"$installer" --test
"$installer" \
  --group='LinuxServers\Pilot' \
  --products=antivirus,xdr \
  --tag=Rollout:wave-0 \
  --tag=ManagedBy:automation

Adapt the group path to your Central structure. If the specified group or subgroup does not yet exist, the installer creates it. Check the path exactly before rollout because a typo can create an unwanted new group. With --products, unlicensed products are not installed. According to the current CLI page, the permitted values are antivirus, mdr and xdr. Multiple --tag=<key>:<value> arguments add device tags. If keys are duplicated, Central shows only the last value supplied.

In this example, set -euo pipefail prevents the script from silently continuing as successful after a failed precheck or installation. The software deployment system must propagate the real exit status and must not retry installation endlessly on failed hosts. Because Sophos does not publish a permanent table of numeric exit codes on the CLI page, acceptance is based on combined local and Central validation, not an invented mapping of codes.

Important installer options

Place environment variables before and command-line options after the installer command.

You can set UIDs and GIDs for the accounts and groups created by SPL with --user-ids-to-configure and --group-ids-to-configure. Use these options only when local identity or hardening requirements mandate fixed IDs. Sophos expressly limits their effect to the documented SPL accounts and groups.

With --install-dir=<basis>, SPL is installed under <basis>/sophos-spl. Adjust every subsequent log, version, registration and uninstall path accordingly; the /opt/sophos-spl/... paths in this article apply to the default installation. AV plugin paths also apply only to hosts with the antivirus product installed.

Specify Message Relay and Update Cache

Normally, SophosSetup.sh includes the relays and caches configured in Central. The installer orders them by numerical proximity to the device IP address and uses the nearest service it can reach. If none is reachable, it contacts Central directly. You can explicitly override the selection during installation:

sudo ./SophosSetup.sh \
  --message-relays=192.0.2.10:8190 \
  --update-caches=192.0.2.10:8191

192.0.2.10 is a documentation address and must be replaced. Sophos specifies port 8190 for Message Relay and 8191 for Update Cache. Setting an option to none forces a direct Central connection for that service. The override applies during installation. Afterwards, the agent resumes using the nearest configured services unless you assign the device manually in Central.

Gold images for virtual Linux systems

Do not clone an installed and registered Linux system unchanged. Deregister the gold-image VM from Sophos Fusion before saving the template. Every clone started from it then registers automatically with its own identity when it starts and reaches the network.

1. Fully prepare the operating system and applications on the master VM.
2. Under My Environment > Installers, download the Linux Server Installer or XDR Sensor Linux Server Installer appropriate for the intended protection mode.
3. Install SPL as described above and validate its state.
4. Change to the registration directory and deregister the master VM:

cd /opt/sophos-spl/base/bin/
sudo ./registerCentral --deregister

5. Shut down immediately and save the image while the VM is powered off.
6. Do not restart the master VM after deregistration. Restarting registers it again; if that happens, deregister it once more before saving.
7. Start at least two clones from the saved image and check that both appear as separate devices in Central.

If you changed the installation location with --install-dir, sophos-spl resides below the specified path. Run the gold-image command from the corresponding base/bin directory of that installation.

Validate the installation

A pilot passes only when all of the following checks succeed:

1. Under My Products > Server > Servers, exactly one expected device object appears for each host. Health, last activity and installed components on the server details page are plausible.
2. The device is in the intended group and receives the server policies appropriate for the components actually installed. Full malware protection requires an effective Server Threat Protection Policy; for update policies, the first matching policy applies.
3. The service is running locally:

sudo systemctl status sophos-spl

4. Only with the antivirus product installed: The Server Protection version shown in Central matches the locally reported version:

sudo cat /opt/sophos-spl/plugins/av/VERSION.ini

Sophos specifies this exact AV plugin file for the version comparison. For an XDR Sensor-only deployment, do not require this file: instead, compare the components actually installed, their displayed versions, health and last activity on the server details page with the selected sensor mode. Locally, check connectivity to Sophos Fusion in the MCS/management log appropriate for the installed version: /opt/sophos-spl/logs/base/sophosspl/management.log or, for LTS packages, possibly the older mcsrouter.log and sophos_managementagent.log. Check log names and paths against the installed package; do not infer sensor functionality merely from the presence or absence of a log or AV path.

5. Only with the antivirus product installed: For the EICAR on-access test, both Real-time scanning - Local files and network shares and Enable scan for Server Protection for Linux Agent must be enabled in the effective Server Threat Protection Policy; the Linux-specific setting is disabled by default. Then verify the detection in /opt/sophos-spl/plugins/av/log/av.log and on the server summary page. An XDR Sensor-only deployment provides neither this malware detection nor on-demand scans; instead, validate the still-active third-party malware protection separately using that vendor’s documented procedure.

Stop the wider wave if devices are missing, appear more than once, remain unhealthy, do not receive the expected components or policies, or interfere with business-critical workloads.

Stop, roll back or remove the rollout

Rollback starts by stopping deployment. Stop new target assignments and automatic retries, contain the affected wave and preserve the last working VM, package or configuration state. Uninstallation does not automatically restore third-party protection that was removed or replaced.

For the complete local removal, cgroup clean-up, verification, Central-record handling and recovery procedure, follow Completely uninstall Sophos Protection for Linux. Keep those removal commands in that runbook rather than copying them into an installation or rollout job.

Tamper Protection is unavailable for Sophos Protection for Linux and is therefore not applicable to this rollback. Still confirm the remaining server policies, restore the intended protection and decide how to handle the Central device record before closing the change.

Troubleshoot by symptom

--test or installation fails

Capture the exact command, distribution, kernel, architecture and output. When the Thin Installer detects an installation failure, it automatically starts Sophos Diagnostic Utility (SDU) and creates sophos_diagnose.tgz in the Thin Installer directory. This archive contains installation logs and system information for Sophos Support.

Run the following only at the request of Sophos Support or for a controlled reproduction. It reruns the installer, enables shell debug output and preserves the temporary installation directory.

sudo OVERRIDE_INSTALLER_CLEANUP=1 \
  DEBUG_THIN_INSTALLER=1 \
  bash -x ./SophosSetup.sh 2>&1 | tee install.log

OVERRIDE_INSTALLER_CLEANUP=1 preserves the temporary /tmp/SophosCentralInstall_<uuid> directory. Logs may contain hostnames, internal paths and network details; review them before sharing.

/tmp is mounted with noexec

Do not permanently relax /tmp. Create a suitable executable temporary path and set it with TMPDIR for the installer only:

sudo TMPDIR=/var/tmp ./SophosSetup.sh --test
sudo TMPDIR=/var/tmp ./SophosSetup.sh

TMPDIR changes only the temporary directory, not the default /opt/sophos-spl installation destination.

The device does not appear in Sophos Fusion

First check DNS, TCP 443, the proxy, TLS inspection and the current domain allowlist. Then inspect the MCS/management log appropriate for the installed version for the selected connection path and a successful connection: /opt/sophos-spl/logs/base/sophosspl/management.log or, for LTS packages, possibly the older mcsrouter.log and sophos_managementagent.log. Check log names and paths against the installed package. Sophos shows examples in the current management.log including Successful connection via environment proxy and Connection method: Proxy.

If a Linux device that is not yet managed cannot obtain the Central proxy configuration, Sophos documents a bootstrap file containing http_proxy=https://<PROXY_ADDRESS>:<PROXY_PORT>: /etc/default/sophos-spl on Debian-based systems and /etc/sysconfig/sophos-spl on RHEL, CentOS and Amazon Linux. Then run:

sudo systemctl restart sophos-spl
sudo systemctl status sophos-spl

Finally, check the MCS/management log appropriate for the installed version (for LTS, possibly mcsrouter.log and sophos_managementagent.log).

Full malware protection is installed but real-time scanning is not working

Only with the antivirus product installed: open the effective Threat Protection Policy under My Products > Server > Policies. Both Real-time scanning - Local files and network shares and Enable scan for Server Protection for Linux Agent must be enabled. For diagnosis, Sophos specifies the local policy files /opt/sophos-spl/base/mcs/policy/CORC_policy.xml and /opt/sophos-spl/plugins/av/var/on_access_policy.json, and the log /opt/sophos-spl/plugins/av/log/soapd.log. This is not an error condition for an XDR Sensor-only deployment; its malware protection must come from a third party.

A custom installation path fails with SELinux Enforcing

Do not work around this with --notest or by disabling SELinux globally. The new base directory must not be a symlink and must not already contain a sophos-spl subdirectory. After creating it, copy the SELinux file-context mapping from /opt to the new path:

sudo semanage fcontext -a -e /opt <PFAD_ZUM_NEUEN_INSTALLATIONSVERZEICHNIS>

Then run the installer with the validated --install-dir. If semanage is missing, first install the appropriate SELinux management package for the distribution; do not disable the security control.

An AV scan target is not scanned or processes are terminated

Only with the antivirus product installed: for a missing scan target, first check its type and mount point with findmnt -rn -o TARGET,FSTYPE. Search /opt/sophos-spl/plugins/av/log/soapd.log for is not supported and will be excluded from scanning. Do not use --notest to force an automatically excluded or undocumented filesystem. Keep the scan target excluded until you use a currently supported type or Sophos Support confirms the specific configuration.

For unexpected process termination, inspect /opt/sophos-spl/logs/base/watchdog.log, then the kernel journal:

sudo journalctl -k -b

Preserve messages containing oom-kill, Memory cgroup out of memory or rejected cgroup values together with the effective cgroup-limits.conf and workload at the time. Do not blindly substitute a higher or lower number: overly generous SPL limits can displace the application, while limits that are too tight can terminate protection processes. Make changes in a maintenance window and follow the local README. Sophos requires stopping sophos-spl.service before editing and starting it afterwards. Then recheck service status, watchdog.log, the journal, Central health and the business-critical application.

Clones share an identity or the template reappears

Stop deployment. Check whether the master was actually shut down after registerCentral --deregister and saved while powered off. If it was restarted, deregister it again before saving. Do not use faulty clones as the next template; recreate them from the correctly prepared gold image.

Frequently asked questions