Error Exiting tar: Previous Errors

Understanding the Error Message

The message "Exiting failure status due to previous errors" serves as a summary line at the end of the tar command execution. It confirms that the archive process did not complete successfully because one or more individual file operations failed. The critical information is not in this final line, but in the lines printed immediately before it. These preceding lines detail the exact cause of each failure, such as "Permission denied," "No such file or directory," or "Read-only file system."

In many cases, users see only the final exit status because they are redirecting or ignoring standard error output. Without seeing the intermediate errors, it is impossible to fix the root cause. Therefore, the first step in troubleshooting is ensuring that all error messages are visible on your terminal screen.

Identifying the Root Cause

To diagnose the problem effectively, you need to run the tar command again and pay close attention to the verbose output. Use the -v (verbose) flag to list every file as it is processed. This helps you see exactly which file caused the interruption. For example:

tar -cvf archive.tar /path/to/directory

If the output is too long or gets scrolled off the screen, redirect the standard error stream to a file for easier analysis. You can do this using the 2> operator:

tar -cvf archive.tar /path/to/directory 2> tar_errors.log

After the command finishes, open tar_errors.log and look for lines containing "Error" or "failed." Common causes include:

• Permission Denied: The user running the command does not have read access to certain files within the directory tree.
• Missing Files: A file referenced in the path was deleted or moved between the time the command started and when it reached that specific file.
• Symlink Issues: Broken symbolic links pointing to non-existent targets.
• Special Files: Attempts to archive device files, sockets, or named pipes which may require special handling or permissions.

Checking Permissions

One of the most frequent causes of this error is insufficient permissions. If you are archiving a directory owned by another user, you will get "Permission denied" errors for those files. You can check the permissions of the source directory using ls -ld /path/to/directory. If you lack read access, you can either change the ownership using chown, adjust permissions with chmod, or run the command with elevated privileges using sudo.

sudo tar -cvf archive.tar /path/to/directory

Using sudo allows tar to read files that would otherwise be inaccessible. However, be cautious when using sudo with large directories, as it may capture sensitive system files you did not intend to archive.

Handling Specific File Types

Depending on the contents of your directory, you might encounter errors related to special file types. For instance, trying to archive a broken symlink will result in an error unless you use the --no-dereference option, which preserves the link itself rather than following it.

tar --no-dereference -cvf archive.tar /path/to/directory

Similarly, if you are archiving a filesystem that contains device nodes (like /dev), tar may refuse to include them by default for safety reasons. You can explicitly exclude these using the --exclude flag if they are not needed in your backup.

Ignoring Errors vs. Fixing Them

In some scenarios, you might want to proceed with archiving despite minor errors, such as temporary network glitches or unimportant permission issues. The tar command offers the --ignore-failed-read option, which tells tar to continue processing even if it cannot read certain files. This suppresses the "Exiting failure status" message if the remaining files are archived successfully.

tar --ignore-failed-read -cvf archive.tar /path/to/directory

Use this option judiciously. While it allows the backup to complete, the resulting archive will be incomplete. Always verify the integrity of the archive afterward if you choose this path. For a comprehensive guide on excluding specific folders during the archiving process, refer to our article on Shell Command to Tar Directory Excluding Certain Folders.

Verifying the Archive

Once you have resolved the underlying errors and created a new archive, it is good practice to verify its contents. You can list the contents of the archive without extracting them using the -t flag:

tar -tvf archive.tar

This command displays the files in the archive along with their permissions and sizes. If the listing completes without errors, the archive was likely created successfully. Additionally, comparing checksums of identical packages can help ensure consistency, as discussed in Why are the MD5 checksums different when tar-ing the same two packages?.

Frequently Asked Questions

Can I ignore all errors and force tar to continue?

Yes, you can use the --ignore-failed-read flag to make tar skip unreadable files and continue archiving. This prevents the "Exiting failure status" message from appearing if other files are processed successfully, though the archive will be partial.

Why does tar fail on symlinks?

By default, tar follows symbolic links, which can cause errors if the target is missing or inaccessible. Using the --no-dereference option forces tar to store the symlink itself, avoiding errors related to broken targets.

How do I see the actual error causing the exit?

The actual errors are printed to standard error just before the final exit message. Run the command with 2> errors.log to save these details to a file, then review the log to identify specific "Permission denied" or "No such file" messages.

Is sudo always required for tar backups?

No, sudo is only required if you lack read permissions for the files being archived. If you own the files or have appropriate read access, you can run tar without elevated privileges.

What should I do if the archive is corrupted?

If you suspect corruption, use tar -tvf archive.tar to list its contents. If the listing fails or shows unexpected results, recreate the archive after fixing the source file issues. Avoid using --ignore-failed-read for critical data where completeness is mandatory.