Unpack Failed

The stage that failed is local, which is the first useful thing to establish. Extraction happens after every byte has arrived, on files already sitting on disk, using the reader's own CPU, filesystem and free space. A provider's completion rate has no bearing on whether an archive opens; it only determines the quality of the input handed to this stage.

Triage in three checks

1. Free space on the volume holding both the archive and the extraction target. This takes seconds to check and it is the most frequent cause.
2. Whether the extractor is reporting an encryption problem. A password prompt, a message naming the headers or the data as encrypted, or a checksum failure on every file in an otherwise clean set all point here.
3. Whether PAR2 verification passed before extraction started. If it never ran, or ran and failed, the input to the extractor was never sound and the unpack error is a downstream symptom.

The three are independent, they produce nearly identical wording in many clients, and working through them in that order resolves most cases without touching a single download setting.

Disk space is the most commonly missed of the three

A RAR set needs the archive and the extracted output present at the same time, so the peak requirement is close to twice the release size, and clients that extract into a working folder before moving the result can need more again during the move. Two filesystem limits catch people out independently of free space. A destination formatted FAT32 refuses any single file larger than 4 GB and fails at exactly the point that limit is reached. A container or virtual machine with a small allocated volume hits its own ceiling long before the host disk does.

A password failure wearing an unpack error's clothes

Encrypted archives fail in two distinguishable ways. If the filenames inside are listed in the client's log, only the data is encrypted and the extractor reached the content before erroring. If the extractor cannot enumerate the contents at all, the headers are encrypted too. Either way the missing item is the password, which usually travels in the NZB metadata or the release's .nfo, and a wrong password commonly surfaces as a checksum error rather than an explicit rejection. That is precisely why it gets mistaken for corruption.

When the archive really is damaged

If verification passed cleanly and space and permissions are fine, the remaining explanations are narrow: the set was rebuilt against recovery data belonging to a different posting of the same release, files from two separate grabs are sitting in one folder, or the release was posted broken. The last is uncommon but real, and it is identifiable because the same release then fails identically for every reader and from every source, which no local or provider-side cause does.