Skip to main content

A downloaded security log archive cannot be opened

Symptom​

You downloaded a security log archive file from the Archived events tab (event archives). The file has a .csv.gz extension but cannot be opened:

  • The archiver reports "not in gzip format" or "invalid format".
  • The downloaded file is noticeably larger than the value in the Size column for this archive row.
  • The downloaded file's checksum does not match the sha256 shown in the table.

Regular CSV and JSON exports of the same log open without problems; only compressed archive files are affected.

How to check​

Verify that this is the issue you are encountering. Check the file type and its checksum, then compare it with the reference value in the archive table.

# 1. File type: an intact archive must start with the gzip signature 1f 8b
file security_log_*.csv.gz

# 2. First bytes: an intact gzip starts with "1f 8b 08 08 ..."
xxd security_log_*.csv.gz | head -1

# 3. Checksum of the downloaded file
shasum -a 256 security_log_*.csv.gz

Signs of a corrupted file:

  • file shows data instead of gzip compressed data.
  • The second byte of the signature differs from 8b (for example, it is replaced by the three bytes ef bf bd).
  • The checksum from step 3 does not match the sha256 value in the archive row.

The security-event-archive-list API method also returns the reference checksum for each archive (the sha256 field). It is the same reference value shown in the interface.

Cause​

The most likely cause (builds from the 3.0.3 branch): the web interface delivers the archive through a path that processes the response body as text. The archive is binary, and text decoding replaces all non-ASCII bytes with a replacement character. This destroys the gzip signature, prevents the file from being decompressed, and inflates its size (each corrupted byte takes up three bytes). This is why the downloaded file is larger than shown in the table and the checksum does not match. The issue affects only binary archive downloads; text exports (CSV/JSON) remain intact.

Other causes are less common:

  • The archive is still being generated. Such a file has no size or checksum in the list (it is marked as incomplete); it is too early to download it.
  • The file was corrupted locally: an interrupted transfer or decompression with the wrong tool. Comparing checksums in step 3 rules this out.

Resolution​

  1. Compare the downloaded file's checksum with the reference value in the table. If they match, the file is intact and the decompression method is the problem; open it with a gzip-compatible archiver.

  2. If the checksums differ and the file is inflated, it has the download corruption described above. Do not try to "repair" it; its contents have been irreversibly altered.

  3. Obtain an intact archive by bypassing the web download. The target file is on the management node in the archive storage directory (by default, /var/db/vstack/security-archive); the security-event-archive-export method returns its path in the file_path field. Retrieve the file directly from the management node (for example, using SCP) and compare the checksum again.

  4. Verify that the resulting file can be decompressed and passes validation:

    gunzip -t security_log_*.csv.gz && echo "archive OK"

Prevention​

  • After every download, compare the file's sha256 with the reference value in the archive list; this immediately detects download corruption.
  • On affected builds, retrieve security log archives directly from the management node rather than through the download button in the interface.
  • Store the reference checksums with the archives: they are needed for integrity checks and confirm that the download was not altered.