additionalimagestores is ignored even inside the same privileged container: a shared store created by Podman cannot be read by another Podman storage root in that same container

[forsaken628]

Description

I believe this is a containers/storage issue rather than a Podman CLI issue.

I can reproduce a case where:

• a shared image store is created by Podman
• the consumer is also Podman
• both producer and consumer run inside the same privileged container
• the consumer uses a separate storage root and points additionalimagestores to the shared store

The shared store is populated successfully and Podman can see the image when using that store directly.

But a second Podman storage root in the same container, configured with:

[storage.options]
additionalimagestores = ["/work/shared/graphroot"]

cannot see the image at all:

• podman images is empty
• podman image exists docker.io/library/ubuntu:latest returns non-zero
• podman build / buildah from --pull=never would also behave as if the image is absent

This is not a host bind mount problem, not a rootless permission problem, and not a cross-machine scenario, because the entire reproducer runs inside one privileged container.

Steps to reproduce

Run this command:

podman run --rm --privileged quay.io/podman/stable:latest sh -eux <<'EOF'
mkdir -p /work/shared/graphroot /work/shared/runroot
mkdir -p /work/consumer/graphroot /work/consumer/runroot

podman
--root /work/shared/graphroot
--runroot /work/shared/runroot
--storage-driver overlay
pull docker.io/library/ubuntu:latest

cat >/work/consumer/storage.conf <<'CONF'
[storage]
driver = "overlay"
runroot = "/work/consumer/runroot"
graphroot = "/work/consumer/graphroot"

[storage.options]
additionalimagestores = ["/work/shared/graphroot"]
CONF

echo '== producer images =='
podman
--root /work/shared/graphroot
--runroot /work/shared/runroot
--storage-driver overlay
images

echo
echo '== consumer images =='
CONTAINERS_STORAGE_CONF=/work/consumer/storage.conf
podman
--root /work/consumer/graphroot
--runroot /work/consumer/runroot
--storage-driver overlay
images

echo
echo '== consumer image exists =='
set +e
CONTAINERS_STORAGE_CONF=/work/consumer/storage.conf
podman
--root /work/consumer/graphroot
--runroot /work/consumer/runroot
--storage-driver overlay
image exists docker.io/library/ubuntu:latest
rc=$?
set -e
echo "exit code: $rc"
EOF

Actual results

The producer side sees the image in the shared store:

== producer images ==
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/library/ubuntu latest f794f40ddfff 5 weeks ago 80.7 MB

But the consumer side sees nothing:

== consumer images ==
REPOSITORY TAG IMAGE ID CREATED SIZE

And image exists reports the image as absent:

== consumer image exists ==
exit code: 1

Expected results

I expect the consumer store to see images from the producer store listed in additionalimagestores, especially in this minimal case where both stores are created and used inside
the same privileged container.

Expected behavior:

• podman images should show docker.io/library/ubuntu:latest
• podman image exists docker.io/library/ubuntu:latest should return success

Why I think this belongs in containers/storage

This reproducer avoids most of the usual Podman-in-Podman complications:

• same privileged container
• same filesystem namespace
• same runtime environment
• same storage driver (overlay)
• producer and consumer are both Podman
• no host bind-mounted rootless store involved

Podman successfully writes and reads the producer store when used directly.
The failure only appears when a second storage root tries to consume that store through additionalimagestores.

That suggests the problem is in how containers/storage recognizes or exposes additional image stores, not in CLI behavior.

Environment

Reproducer container:

• Image: quay.io/podman/stable:latest
• Podman: 5.8.1

podman --version:

podman version 5.8.1

Host environment where I originally noticed the issue:

• Podman: 4.9.3
• Ubuntu 24.04
• kernel: 6.6.87.2-microsoft-standard-WSL2

But the reproducer above does not depend on the host storage layout and happens fully inside a single privileged container.

[github-actions]

This repository has been migrated to https://github.com/containers/container-libs. Please open your issue there.