How to Resolve "tar: Error is not recoverable: exiting now" During Extraction

tar aborts mid-extraction with a blunt "not recoverable" message instead of finishing, and unlike many tar warnings, this one means the process stopped completely rather than skipping a problem file and continuing. It's tar's way of saying it hit something it fundamentally can't work around.

The Problem

Extracting an archive dies partway through, often after successfully extracting some files first:

$ tar -xzf backup.tar.gz
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
tar: Error is not recoverable: exiting now

It sometimes appears alongside a more specific complaint just before it:

$ tar -xzf backup.tar.gz
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Why It Happens

This message means tar encountered a structural problem with the archive itself that it can't recover from mid-stream — unlike a single corrupted file inside an otherwise fine archive, which tar can often skip past. Common causes:

• The archive is genuinely corrupted or truncated — an incomplete download, an interrupted transfer, or a backup process that got killed before finishing writing the file.
• Wrong compression flag for the actual file format — using -z (gzip) on a file that's actually bzip2 or xz compressed, or vice versa, confuses the decompression stream partway through.
• Ran out of disk space during extraction, which can produce a confusing tar-level error rather than a clear "disk full" message depending on how the failure surfaces.
• The archive was created on a different system with an incompatible tar variant or unusual archive features (sparse files, extended attributes) that this tar version can't fully parse.

The Fix

First, confirm the archive's actual file type rather than trusting its extension, since a mismatched compression flag is one of the most common causes:

file backup.tar.gz

backup.tar.gz: bzip2 compressed data, block size = 900k

If file reports something different from what the extension implies (a .tar.gz that's actually bzip2, as above), use the matching flag instead of assuming from the filename:

tar -xjf backup.tar.gz

Or let tar auto-detect the compression instead of specifying it manually:

tar -xaf backup.tar.gz

Check available disk space before extracting, especially for large archives:

df -h .

If space is tight, free some up or extract to a different volume with more room:

tar -xzf backup.tar.gz -C /mnt/bigger-disk/

Verify the archive's integrity independently of extraction, which confirms whether the file itself is actually corrupted:

gzip -t backup.tar.gz

gzip: backup.tar.gz: unexpected end of file

If that confirms corruption, the file itself is damaged — re-download or re-generate it rather than trying different extraction flags, since no combination of tar options can recover data that isn't actually there.

Still Not Working?

If the archive came from a network transfer, compare its checksum against the source to rule out silent corruption during the copy, rather than assuming the extraction command is at fault:

sha256sum backup.tar.gz

Compare this against a checksum generated at the source before the transfer. If they don't match, re-transfer the file using a method that verifies integrity (rsync with checksums, or scp followed by a checksum comparison) rather than a plain download that might silently truncate on a flaky connection:

rsync -avz --checksum user@source:/path/backup.tar.gz .

For partially extracted archives where you only need whatever data did extract successfully before the failure, list the archive's contents first to see how far it actually got, then extract just the files you can confirm are intact:

tar -tzf backup.tar.gz 2>/dev/null

It's also worth checking whether the archive was created with a tar variant that adds features your extraction tool doesn't fully support. GNU tar and BSD tar (the default on macOS) handle certain edge cases — sparse files, extended attributes, very long filenames — slightly differently, and an archive created with one can occasionally trip up the other on unusual content, even though the vast majority of archives extract identically on both. Checking which tar implementation you're running can rule this out as a variable:

tar --version

If you suspect a version mismatch is contributing to the problem and re-downloading or re-verifying the source doesn't resolve it, try extracting with the GNU tar explicitly if it's available under a different name, which is common on macOS via Homebrew:

brew install gnu-tar
gtar -xzf backup.tar.gz

For archives you create yourself going forward, adding a verification step right after archiving catches corruption immediately, before the file gets moved, backed up, or transferred anywhere — which is far cheaper than discovering the problem weeks later when you actually need to restore from it:

tar -czf backup.tar.gz /data/ && tar -tzf backup.tar.gz > /dev/null && echo "Archive verified OK"