Upload an Existing sos Report Safely with sos upload

The report is collected and cleaned, and now it needs to reach support: sos upload sends a report or other file to a configured destination. Version 4.10.2 is used here, package 4.10.2-0ubuntu0~24.04.1. Allow about fifteen minutes, plus time to confirm the destination and archive are appropriate.

Uploading is an external data transfer. sos reports can contain hostnames, addresses, usernames, logs and other sensitive material, so review the archive first and use sos clean or your organisation's approved handling process when redaction is required. These examples do not create a report, change policy or restart a service. They also do not need sudo unless the file or its directory is deliberately readable only by root.

1. Check the installed command

Confirm the executable, package version and supported upload options before choosing a destination:

$ command -v sos
/usr/bin/sos
$ dpkg-query -W -f='${Package} ${Version}\n' sosreport
sosreport 4.10.2-0ubuntu0~24.04.1
$ sos upload --help
usage: sos upload FILE [options]

The required positional argument is FILE. It can be a previously generated report or another file. This subcommand is separate from sos report --upload: it is useful when the archive was generated on one system and must be sent from another.

Checkpoint: Do not continue until you have the exact path of the file and have checked its contents under your organisation's data-sharing rules.

2. Choose the upload target

There are two broad modes. A vendor target lets sos choose vendor-specific behaviour. The installed command accepts redhat, canonical, generic and local with --upload-target. If you omit that option, sos tries to determine a local target.

For a vendor workflow, use the target named by that vendor and add a case identifier when required:

$ sos upload /path/to/sosreport.tar.xz \
    --upload-target redhat \
    --case-id CASE123456

Replace both placeholders. The manual specifies that a Red Hat case identifier may contain letters, numbers, commas and full stops. Vendor defaults can supply the upload address or method. If the vendor has not supplied a usable default, set the URL and credentials explicitly instead.

For an organisation-owned server, select generic and provide an address whose scheme identifies the protocol. The local manual supports HTTPS, SFTP and FTP URLs, and also an S3 protocol with its separate S3 options:

$ sos upload /path/to/sosreport.tar.xz \
    --upload-target generic \
    --upload-url https://uploads.example.invalid/sos/ \
    --upload-directory incoming \
    --upload-method put

The .invalid host above is an example placeholder, not a destination you can use. Replace it only after confirming the hostname, path and expected HTTP method with the receiving team. --upload-method accepts auto, put and post, and applies only to HTTPS. Use auto when the policy or receiver has not specified otherwise.

3. Supply credentials without putting a password in the command

Give a username with --upload-user when the destination needs one. If you omit --upload-pass, sos prompts for the password during an interactive upload:

$ sos upload /path/to/sosreport.tar.xz \
    --upload-target generic \
    --upload-url sftp://uploads.example.invalid/incoming \
    --upload-user report-uploader
Password:

Do not paste a real password into a command containing --upload-pass. The manual warns that it can be visible in ps output and may be collected into a sos archive. The installed command also supports the SOSUPLOADUSER and SOSUPLOADPASSWORD environment variables, but the password remains sensitive process environment data. Prefer the interactive prompt when a human is available, and keep automated credentials in the secret store and execution mechanism approved for your service.

--batch disables prompts. That makes unattended use possible only when every required value is already available, including the password. It is not a way to avoid authentication:

$ sos upload --batch /path/to/sosreport.tar.xz \
    --upload-target generic \
    --upload-url https://uploads.example.invalid/sos/ \
    --upload-user report-uploader \
    --upload-pass 'READ_FROM_YOUR_SECRET_MANAGER'

The value in this example is deliberately not a usable secret. Do not replace it with a real password in a shell history. For a scheduled job, arrange secret injection outside the command line and test that the job cannot print the secret in diagnostics.

4. Verify the file and destination before sending

Run local checks before the upload command. These are ordinary, unprivileged reads:

$ test -r /path/to/sosreport.tar.xz
$ stat --printf='file=%n bytes=%s\n' /path/to/sosreport.tar.xz
file=/path/to/sosreport.tar.xz bytes=1234567
$ file /path/to/sosreport.tar.xz
/path/to/sosreport.tar.xz: XZ compressed data

The byte count and file description will vary. Check that the path is the intended archive, that it is non-empty, and that its permissions do not expose more data than intended. Check the destination separately with the receiving team. A syntactically valid URL can still point at the wrong account or an untrusted service.

When the URL does not include a scheme, use --upload-protocol only when you have a specific reason to override normal detection. Its accepted values are auto, https, ftp, sftp and s3. For S3, the installed command also exposes --upload-s3-endpoint, --upload-s3-region, --upload-s3-bucket, --upload-s3-access-key, --upload-s3-secret-key and --upload-s3-object-prefix. Treat access and secret keys like passwords, and do not put them in a transcript or shared shell history.

5. Make the transfer and read its result

Once the archive, target and authentication method have passed the checkpoints, run the prepared command. Start interactively unless your automation has already been tested:

$ sos upload /path/to/sosreport.tar.xz \
    --upload-target generic \
    --upload-url https://uploads.example.invalid/sos/ \
    --upload-user report-uploader
Password:
sos upload (version 4.10.2)
... upload status is reported here ...
$ printf 'exit status: %s\n' "$?"
exit status: 0

Do not treat the sample status text as a fixed transcript: the receiver, protocol and package build determine the messages. The useful local checks are the command's final status and confirmation from the receiving system that the expected object or archive arrived. A zero status does not prove that the recipient has retained or correctly processed the data.

For HTTPS, leave certificate verification enabled. --upload-no-ssl-verify disables it for self-signed or otherwise untrusted certificates, which removes an important identity check. Use that option only under an explicit, documented exception with a trusted alternate path for validating the server. Never add it just because a certificate error is inconvenient.

6. Diagnose failures without resending blindly

A missing local file fails before a transfer. Recheck the path and permissions:

$ sos upload --batch /tmp/does-not-exist-sos-upload \
    --upload-target generic \
    --upload-url https://uploads.example.invalid/sos/ \
    --upload-user demo \
    --upload-pass 'not-a-real-password'
Cannot upload /tmp/does-not-exist-sos-upload: [Errno 2] No such file or directory
$ printf 'exit status: %s\n' "$?"
exit status: 1

The exact wording can differ, but a missing path is a local input problem. For authentication failures, check the account, destination policy and protocol with the receiver. For an HTTP method error, confirm whether the endpoint expects PUT or POST. For SFTP or FTP, check the remote directory and whether --upload-directory is required.

If a transfer might have succeeded before the client reported an error, do not immediately retry and create a duplicate. Ask the receiver to check its records or object key first. The upload command does not provide a general undo for data already sent. Recovery means removing the received object through the destination's approved process, rotating credentials if they were exposed, and recording any disclosure according to your incident procedure.

Done means