When using tar --preserve-permissions (-p) for backups, many administrators encounter surprises during restoration when user/group IDs (UID/GID) differ between systems. The critical detail often overlooked is that tar actually stores numeric UIDs/GIDs in the archive, not usernames.

# Example archive contents showing numeric IDs
$ tar tvf backup.tar
-rw-r--r-- alice/users 685 2023-01-01 12:00 /home/alice/important.txt
# Underlying storage actually records UID 1001, GID 1002

When restoring with tar -xpzf backup.tar on a system where:

• User "alice" now has UID 2001 (was 1001 on source)
• Group "users" now has GID 2002 (was 1002 on source)

The files will be owned by UID 1001/GID 1002 numerically, which typically results in:

$ ls -l restored_file
-rw-r--r-- 1 1001 1002 685 Jan 1 12:00 important.txt

Option 1: Use --numeric-owner during extraction

tar -xpzf backup.tar --numeric-owner

This explicitly tells tar to use the numeric IDs from the archive, avoiding any name resolution.

Option 2: Remap IDs during extraction

tar -xpzf backup.tar --owner-map=uid_map.txt --group-map=gid_map.txt

Where uid_map.txt contains:

1001 2001  # Map source UID 1001 → target UID 2001
1002 2002  # Map source GID 1002 → target GID 2002

Option 3: Post-restoration ID correction

find /restore/path -uid 1001 -exec chown alice {} +
find /restore/path -gid 1002 -exec chgrp users {} +

For containerized environments where UID/GID mapping is common:

# Backup with namespace context
tar -cpzf backup.tar --xattrs --xattrs-include='*' --acls /path

# Restore with proper namespace mapping
tar -xpzf backup.tar --xattrs --xattrs-include='*' --acls \
    --owner-map=container_uids.txt

• Tar fundamentally works with numeric IDs, not usernames
• The -p flag preserves numeric permissions from the source
• For consistent results across systems, plan your UID/GID strategy before backup
• Modern tar versions (≥1.29) offer robust mapping options

When using tar --preserve-permissions (or -p flag), tar stores both the numeric UID/GID and the username/groupname in extended attributes (when available). During restoration:

# Example archive creation with full permissions
tar -cvpf backup.tar --xattrs --xattrs-include='*' /path/to/data

During extraction, tar follows this priority sequence:

1. Attempts to match the original numeric UID first
2. Falls back to username mapping if UID doesn't exist
3. Uses current process UID if both fail

Let's validate with a concrete test case:

# Original system (UID 1001 = userA)
$ tar -cvpf test.tar --xattrs --xattrs-include='*' testfile

# Destination system (UID 1005 = userA)
$ tar -xvp --same-owner -f test.tar

The --same-owner flag is critical here. Without it, files will be owned by the extracting user.

For complex migrations, consider these approaches:

# Method 1: Explicit UID mapping during extraction
$ tar -xvpf backup.tar --owner-map=./uid_map.txt --group-map=./gid_map.txt

# uid_map.txt content example:
olduid newuid username
1001 1005 userA

# Method 2: Using --numeric-owner flag
$ tar -xvpf backup.tar --numeric-owner

Behavior varies across filesystems:

• EXT4: Fully supports xattr preservation
• NFS: May require nfs4_getfacl/nfs4_setfacl
• ZFS: Needs --acls flag for complete permission sets

Diagnostic commands when facing problems:

# Check stored attributes
$ getfattr -d -m - testfile

# Verify tar header info
$ tar -tvf backup.tar --full-time --numeric-owner