Collect a Safer sos Report Before You Share It

Support asks for an sos report, and five minutes later you are staring at an archive full of hostnames, addresses and half your config tree. This guide collects a focused report, checks where it landed, and produces a cleaned copy before anything leaves the machine. It covers sosreport version 4.10.2-0ubuntu0~24.04.1, and the whole job takes 15 to 30 minutes plus review time.

Shell access with enough free space for temporary data and the final archive.
A destination ready, such as an open support case, for the result.
Elevated privileges for most collection commands, since they read logs and system configuration.

Do not paste an archive into a ticket until you have inspected it or run the cleaner.

1. Check the installed command

Confirm the command and package before you touch anything else. It saves a confusing troubleshooting session later, when a different host turns out to be running an older sos release with different flags.

$ command -v sos
/usr/bin/sos
$ dpkg-query -W -f='${Package} ${Version}\n' sosreport
sosreport 4.10.2-0ubuntu0~24.04.1
$ sos --help | sed -n '1,12p'
usage: sos <component> [options]

The top-level command selects a component. The usual one is sos report. The aliases rep for report and clean, cleaner and mask for cleaning are documented, but the full names are clearer in scripts and support notes.

2. Review the collection plan

Before running a report, inspect the available plugins and their options. This reads information only and does not collect an archive.

$ sos report --list-plugins
$ sos report --help | less

Watch the scope before you run anything. A report can include configuration files, command output, logs and environment information, and the exact set depends on which plugins are enabled and what the machine has installed. The help output lists the levers for trimming it down:

--skip-plugins drops entire plugins from the run.
--skip-files excludes named paths.
--skip-commands excludes named commands.
--no-env-vars leaves environment variables out.
--log-size caps how much of each log gets copied.

Checkpoint: write down any data the support request does not need. If you only need storage diagnostics, for example, consider whether unrelated application plugins should be skipped. Do not guess plugin names: copy them from --list-plugins.

3. Run a deliberately scoped report

Run the collection with sudo when the support issue spans the whole host. Use a case identifier and a label that make the resulting file recognisable. This example avoids interactive prompts and limits ordinary log collection to 100 MiB.

$ sudo sos report --batch \
    --case-id CASE-12345 \
    --label web-01 \
    --log-size 100

Replace CASE-12345 and web-01 with real values. Do not put passwords, API tokens or other secrets in labels or case identifiers: they can become part of report metadata or shell history.

The command writes progress and eventually reports the archive path. The archive is normally created after a temporary working phase. If you need to preserve the unpackaged result for inspection instead, --build keeps the temporary directory and does not package it. That can consume substantially more disk space, so use it only when you have a reason.

Checkpoint: copy the final path from the command output and verify it without opening the archive yet:

$ report_path=/path/from/sos/output.tar.xz
$ sudo test -s "$report_path" && sudo file "$report_path"
/path/from/sos/output.tar.xz: XZ compressed data

The exact filename and compression depend on the run. The global --compression-type option accepts auto, gzip or xz. The default is auto on this installed command.

4. Protect the archive before sharing

An sos report is diagnostic evidence, not a harmless log bundle. It can contain hostnames, addresses, network details, usernames, configuration and command output. The manpage describes sos clean as a way to obfuscate potentially sensitive networking information while keeping replacements consistent across the report.

Make a separate destination first, then clean into that workflow. Do not clean the only copy when you may need the original for local investigation.

$ mkdir -m 700 /tmp/sos-cleaned
$ sudo sos clean \
    --batch \
    --archive-type auto \
    --keywords 'INTERNAL-NAME,PRIVATE-TOKEN' \
    "$report_path"
$ find /tmp -maxdepth 2 -type f -name '*sos*' -printf '%p %s bytes\n'

The cleaner accepts an archive, a collection of archives or an unpackaged report directory. Its output and naming can vary by archive type and package release, so use the path it prints rather than assuming a filename. The --keywords value is a comma-separated list of extra strings to obfuscate. Keep the original report in a restricted directory until the cleaned result has been checked.

Do not use --disable-parsers or --skip-cleaning-files casually. Those options reduce protection. Certificate private keys are removed by the cleaner; other certificate handling defaults to obfuscation. If the cleaner cannot process a file, review its warning rather than quietly uploading the uncleaned archive.

5. Inspect what you are about to send

List the cleaned archive without extracting it into a shared directory. For a tar archive, the following checks are useful after identifying the actual file:

$ file /tmp/sos-cleaned/REPORT-FILE
$ tar -tf /tmp/sos-cleaned/REPORT-FILE | sed -n '1,40p'
$ tar -tf /tmp/sos-cleaned/REPORT-FILE | rg '(^|/)(etc|var/log|proc|sys)/' | sed -n '1,40p'

Replace REPORT-FILE with the cleaned archive path. Do not treat a clean filename as proof that the contents are safe. Search the extracted or listed paths for data your organisation forbids sharing, and use your support provider's secure upload mechanism. The top-level sos upload component can upload an input file to a policy-defined or user-defined target, but do not use it until you have verified the destination, authentication method and transport policy.

6. Use configuration without losing control

For repeatable local collection, sos reads /etc/sos/sos.conf. A non-root user can also have $HOME/.config/sos/sos.conf for components that support non-root operation. The loading order matters: defaults are followed by system configuration, then user configuration, report presets, and finally command-line values. Later values win.

Configuration is INI-style. Sections are processed as [global], a component section such as [report], then [plugin_options]. For example, a local policy can make batch mode and a thread count consistent:

[global]
batch = yes
threads = 4

[report]
skip-plugins = host,filesys

[plugin_options]
rpm.rpmva = off

Treat /etc/sos/sos.conf, user configuration, presets and the extras.d directory as executable policy. The manpage warns that extras files can execute commands and do not receive secret obfuscation. Review changes as code, keep them narrowly scoped, and prefer a command-line override for a one-off run. Verify the effective report options with sos report --help and the relevant preset or plugin listing before collecting.

7. Clean up temporary copies

Once the cleaned archive has been accepted by support and you have kept only what policy requires, remove the temporary copies from the restricted directory.

Warning: this step is destructive. Confirm the path before you run the remove command.

$ find /tmp/sos-cleaned -maxdepth 1 -type f -print
$ sudo rm -- /tmp/sos-cleaned/REPORT-FILE
$ rmdir /tmp/sos-cleaned

If you deleted the wrong temporary copy, recovery depends on the filesystem and backups. Keep the original report elsewhere until the case is complete, but protect it with filesystem permissions and your normal retention policy.

Done means

The installed sos version and the report scope were checked before collection.
The report was created with a case identifier and a bounded log size where appropriate.
The archive path and non-zero file size were verified.
A separate copy was cleaned, then inspected before upload.
Configuration and extras files were treated as executable policy, not passive text.
Temporary files were removed only after their exact paths were confirmed.