Rootless Podman Export Ownership Shift Explained

Rootless Podman can export a container image or container filesystem where file ownership appears changed, yet the export command still completes successfully because user namespace remapping is applied at export time and the tar stream itself is valid. The ownership shift is not an error; it is the expected consequence of running Podman in rootless mode, where UIDs and GIDs inside the container are mapped to unprivileged host UIDs, and the export process writes those mapped values into the archive.

Background: How Rootless Podman Handles User Namespaces

Podman is a daemonless container engine that can run containers without root privileges. In rootless mode, Podman creates a user namespace for each container. Inside that namespace, the container’s root user (UID 0) is mapped to the invoking user’s host UID (for example, 1000), and other container UIDs are mapped to a range of subordinate UIDs allocated to that user, typically defined in /etc/subuid. This mapping is what allows an unprivileged user to run processes that appear to be root inside the container while remaining unprivileged on the host.

When you run podman export on a container, Podman creates a tarball of the container’s filesystem. For a rootless container, the filesystem is stored on the host with the mapped UIDs (e.g., files owned by root in the container are owned by UID 1000 on the host). The export process reads those host-level ownership values and writes them into the tar headers. Because the tar format simply records numeric UID and GID values, the export succeeds even though the resulting archive shows ownership that differs from what was inside the container.

How Export Works in Rootless Mode

The podman export command creates a tarball from a container’s filesystem, not from an image. It is often used to back up a container’s state or to transfer a filesystem to another system. The command syntax is:

podman export [OPTIONS] CONTAINER

For example, to export a running container named myapp to a file:

podman export myapp > myapp.tar

Under the hood, Podman uses the tar library to walk the container’s root filesystem and write each file’s content and metadata, including ownership. In rootless mode, the ownership values are taken from the host’s view of the files, which are already remapped. The export does not re-map the IDs back to the container’s internal IDs; it simply serializes what it sees. This is why the exported tar may show UID 1000 for files that were owned by root inside the container.

Why the Export Still Succeeds

The export succeeds because there is no validation that the UIDs in the tar match the container’s internal UIDs. The tar format is agnostic to user namespaces; it just stores numbers. Podman’s export code does not fail when the ownership values are not what a user might expect. The only conditions that would cause an export to fail are filesystem errors, permission errors on the output file, or lack of read access to the container’s files. Since rootless Podman has full read access to the container’s storage (which is owned by the user), the export completes normally.

Additionally, the tar archive itself is perfectly usable. Tools like tar -tf will list the files, and extracting the archive will create files with the recorded UIDs (subject to the extracting user’s permissions). The shift in ownership is a data transformation, not a corruption.

How to Choose the Right Export Method

If you need to preserve the original container ownership (UID 0 for root-owned files), you have a few options:

• Use podman commit and podman save: These commands work with images, not containers. When you commit a container to an image and then save it, Podman stores the image layers with the container’s internal UID mapping metadata. The resulting tar can be imported elsewhere and the ownership will be restored correctly.
• Run the export as root: If you have root access, running sudo podman export will produce a tar with the original UIDs, because the container’s files are then accessed without user namespace remapping.
• Use podman cp for individual files: If you only need a few files, podman cp copies files out of the container and can preserve ownership if run with appropriate privileges, but in rootless mode it will also apply the host mapping.

For most backup and transfer purposes, the ownership shift is irrelevant because the tar will be imported back into a rootless Podman environment where the same mapping applies. If you are moving to a rootful environment, you may need to adjust ownership after extraction.

Common Problems and Misconceptions

A frequent misconception is that the export is broken or that Podman is losing data. The data is intact; only the numeric UID/GID values are different. Another issue users encounter is that after importing the tar into a different user’s rootless Podman, the files appear owned by the wrong user. This happens because the subordinate UID range differs between users. For example, if user A exports a tar with UID 1000 (their host UID), and user B imports it, the files will be owned by UID 1000 on user B’s host, which may not be mapped to root in B’s user namespace.

Another common problem is that podman export does not include image metadata, layers, or history. It is a flat filesystem snapshot. If you need a full image with its history, use podman save instead. Also, exporting a container that is running may produce an inconsistent snapshot because files can change during the read. It is recommended to stop the container before exporting.

Comparison: Rootful vs. Rootless Export

In rootful mode, Podman runs with full host privileges and does not use a user namespace by default. The container’s files are stored with their original UIDs on the host, so podman export produces a tar with those same UIDs. In rootless mode, the files are stored with remapped UIDs, so the export reflects that mapping. This difference is the root cause of the ownership shift.

It is also worth noting that podman save (which exports an image) is not affected by this issue in the same way. Image layers are stored in a content-addressable format and the UID mapping is recorded in the image manifest. When you load the image on another system, Podman applies the appropriate mapping for that user, so ownership appears correct inside the container.

Safety and Best Practices

When exporting containers, always verify the integrity of the tar file by checking its size and listing its contents. If you plan to transfer the tar to another system, consider using gzip to compress it, but be aware that compression does not affect ownership. For critical backups, test the import on a separate system to ensure the filesystem is usable.

If you need to preserve ownership exactly, prefer podman commit followed by podman save. This method is the most reliable for moving containers between environments because it preserves the image format and metadata. For quick snapshots, podman export is fine, but understand that ownership will be remapped.

Frequently Asked Questions

Why do my exported files show UID 1000 instead of root?

In rootless mode, your host UID (often 1000) is mapped to root inside the container. The export process writes the host UID into the tar, so files that were owned by root in the container appear as UID 1000 in the archive.

Can I change the ownership back after export?

Yes, you can extract the tar and then use chown to change ownership. For example, tar -xf myapp.tar && sudo chown -R 0:0 . will set all files to root. However, this is only necessary if you are moving to a rootful environment or need the original IDs.

Does podman export include the container’s layers?

No, podman export produces a flat filesystem tar, not an image. It does not include layer history or metadata. Use podman save to export an image with its layers.

Is it safe to export a running container?

It is generally safe, but the snapshot may be inconsistent because files can change during the export. For a consistent backup, stop the container first.

Why does the ownership shift not happen with podman save?

podman save exports an image, not a container filesystem. Images store UID mappings in their metadata, so when loaded, Podman applies the correct mapping for the current user, preserving the perceived ownership inside the container.

Related

• Commodore 64 VICE Setup Guide for Development
• Share Samsung Calendar on Galaxy Phones
• How to Choose a Cloud Incident Response Model