Skip to content
Latchkey

tar --no-same-owner: Own Extracted Files (CI Errors)

tar --no-same-owner makes you the owner of extracted files instead of the archived uid/gid.

Archives store the original owner. Restoring it requires root, so in containers and unprivileged CI the safe default is to take ownership of what you extract.

What it does

tar --no-same-owner extracts files owned by the user running tar rather than the uid and gid stored in the archive. For non-root users this is already the default; for root it is the opposite default, so root extractions use --no-same-owner to avoid restoring arbitrary uids. The mirror flag --same-owner forces restoring stored ownership.

Common usage

Terminal
tar -xf archive.tar --no-same-owner
sudo tar -xf release.tar -C /opt --no-same-owner   # files owned by root
tar -xf archive.tar --same-owner                   # force stored uid/gid

Options

FlagWhat it does
--no-same-ownerExtracted files owned by the current user
--same-ownerRestore the stored uid/gid (needs privilege)
--numeric-ownerUse stored numeric ids, skip name lookups
--owner / --group (create)Override owner names when creating

In CI

In a Docker build or rootless runner, restoring a stored uid that does not exist on the host causes chown failures. Extract with --no-same-owner so the files belong to the build user, which is what subsequent steps expect anyway.

Common errors in CI

tar: ./file: Cannot change ownership to uid 1000, gid 1000: Operation not permitted means tar tried to restore stored ownership without privilege. Add --no-same-owner so tar does not attempt the chown, which clears the warning and avoids the related non-zero exit.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →