Best practice for moving volumes to a different host. SELinux doubts/confusion.

[ro62t2]

I am moving an application to a new server.

I used podman volume export on the original server to export its volume to a .tar file. On my first attempt at restoring the volume on the new server, I used podman volume create then podman volume import before starting up the container. This caused file ownership issues: the volume, and _data directory inside it, were owned by root instead of the uid running the container (set by SubUIDMap & SubGIDMap in a systemd quadlet)

I remedied this by:

• Deleting the volume
• Starting the container to initialize the volume with the correct ownership
• Emptying the _data directory
• Running podman import to import the .tar file into the volume.

Everything seems to be working now, but the selinux labelling is concering me.

Files that were created during initialization by the container are labeled:

system_u:object_r:container_file_t:s0

Where as files that were written during the import are labeled:

unconfined_u:object_r:container_file_t:s0

I was able to fix this with restorecon -RF so I'm fairly sure everything is as it should be now.

I have attempted the same export/import procedure on a VM with the same results, proving it wasn't an issue with the original volume. Is this normal? Am I doing this correctly or is there a better way?

Edit:

Another issue I have when moving volumes:

The container on the new host may have to run in a differently numbered user namespace. I'm worried that I'd break something if I manually chown the contents, especially if there are multiple users in the container. Is there an established best practice for transposing the user namepsace?

[mg1986jp]

The unconfined_u:object_r:container_file_t:s0 labeling on imported files is expected — podman volume import runs as your user (which is unconfined_u in most desktop/server SELinux configs), so tar extraction inherits that user context. restorecon -RF on the volume _data dir is the right fix and you're good.

For the workflow itself, there's a cleaner path than the delete-recreate dance:

# On source host
podman volume export myvolume > myvolume.tar

# On target host - create & import in one shot
podman volume create myvolume
podman volume import myvolume myvolume.tar

# Fix SELinux labels
sudo restorecon -RF $(podman volume inspect myvolume --format '{{.Mountpoint}}')

The ownership issue you hit (root instead of mapped UID) happens because podman volume create makes _data owned by your host UID, and podman volume import extracts with the UIDs from the tar. If the tar was created in a different user namespace, the UIDs won't match. Starting the container first "fixes" it because the OCI runtime sets up the correct idmap on the volume mount.

A more reliable approach: use --chown with podman unshare:

podman volume create myvolume
podman volume import myvolume myvolume.tar
# Remap ownership to match the new userns
podman unshare chown -R 0:0 $(podman volume inspect myvolume -f '{{.Mountpoint}}')

podman unshare runs in the user namespace of your rootless podman, so chown 0:0 maps to the correct subordinate UID on the host. This handles the case where the source and target hosts have different subuid ranges.

For containers with multiple users (e.g., UID 0 owns some files, UID 999 owns others): podman unshare preserves relative ownership. The UIDs inside the tar are container-relative, and podman unshare applies the local userns mapping. So if your tar has files owned by 0 and 999, they'll map correctly as long as your subuid range covers both — which it does by default (65536 range).