Run a self-build image with --userns=keep-id, then the image size will increase

[phiblar]

Issue Description

An image is generated from a Dockerfile, on the condition that no user is specified. As soon as the container is created and started with the --userns=keep-id parameter, the image size nearly doubles. What is the reason for the increase in image size? Are there alternative solutions which I can use?

Steps to reproduce the issue

1. $ podman build --squash --tag fedora.buildenv -f /path/to/Dockerfile

2. $ podman images

3. $ podman run -di --userns=keep-id localhost/fedora.buildenv:latest 

4. $ podman images

Describe the results you received

before podman run

$ podman images
REPOSITORY                         TAG               IMAGE ID      CREATED        SIZE
localhost/fedora.buildenv          latest            edbe624b0ac9  3 minutes ago  9.52 GB

after podman run

$ podman images
REPOSITORY                         TAG               IMAGE ID      CREATED        SIZE
localhost/fedora.buildenv          latest            edbe624b0ac9  6 minutes ago  18.8 GB

[Luap99]

Because as rootless we cannot use idmapped mounts so when you create a userns all the files must be copied and then chown'ed to the new uid/gids which is also why the first run with --userns=keep-id is so slow to start up, see https://github.com/containers/podman/blob/main/docs/tutorials/performance.md#choosing-a-storage-driver

[phiblar]

Thank you. Is it possible to create the user namespace with podman build or in the Dockerfile itself, without having to copy all files and change their ownership to the new UID/GIDs as soon as the container is started with --userns=keep-id?

[jwcard]

Yes, I am also interested in this as well. I am trying to keep the size on disk as minimal as possible. I am creating the image using the same user that will run the container although I do use --uidmap and --guidmap and I tried using the userns-uid-map option to podman build hoping to create an image that would be run as a container with the "chown" already performed and hence only have a single copy. But that didn't have any effect on the final image size.

I also thought about using podman create to create the image and then podman commit followed by podman save but that didn't help at all.

In my case, I don't care about the startup time but do care about the disk space and unfortunately, I need to use rootless.

I'm wondering if exporting the container and then running chown and then importing that back would help? Is this just an unsolvable issue in a rootless mode?

[eriksjolund]

An alternative solution is to use fuse-overlayfs instead of native overlay

I listed the image size with podman images after running

podman run --rm --userns=keep-id registry.fedoraproject.org/fedora /bin/true

type	image size after podman run --rm --userns=keep-id ...
native overlay	636 Mb
fuse-overlayfs	318 Mb

Click to expand all the details of the tests

native overlay

1. Create user test1

   sudo useradd test1
   

2. Open an interactive shell session for user test1

   sudo machinectl shell --uid=test1
   

3. Pull the image

   podman pull -q registry.fedoraproject.org/fedora
   

4. List images

   podman images
   

   The following output is printed

   REPOSITORY                         TAG         IMAGE ID      CREATED       SIZE
   registry.fedoraproject.org/fedora  latest      a8accd4685fe  23 hours ago  318 MB
   

   result: the size of the image is listed as 318 MB
5. Run podman with --userns=keep-id

   podman run --rm --userns=keep-id registry.fedoraproject.org/fedora /bin/true
   

6. List images

   podman images
   

   The following output is printed

   REPOSITORY                         TAG         IMAGE ID      CREATED       SIZE
   registry.fedoraproject.org/fedora  latest      a8accd4685fe  23 hours ago  636 MB
   

   result: the size of the image is listed as 636 MB

fuse-overlayfs

1. Create user test2

   sudo useradd test2
   

2. Open an interactive shell session for user test2

   sudo machinectl shell --uid=test2
   

3. Create directory

   mkdir -p ~/.config/containers
   

4. Create the file ~/.config/containers/storage.conf containing

   [storage]
   driver = "overlay"
   [storage.options.overlay]
   mount_program = "/usr/bin/fuse-overlayfs"
   

5. Pull the image

   podman pull -q registry.fedoraproject.org/fedora
   

6. List images

   podman images
   

   The following output is printed

   REPOSITORY                         TAG         IMAGE ID      CREATED       SIZE
   registry.fedoraproject.org/fedora  latest      a8accd4685fe  23 hours ago  318 MB
   

   result: the size of the image is listed as 318 MB
7. Run podman with --userns=keep-id

   podman run --rm --userns=keep-id registry.fedoraproject.org/fedora /bin/true
   

8. List images

   podman images
   

   The following output is printed

   REPOSITORY                         TAG         IMAGE ID      CREATED       SIZE
   registry.fedoraproject.org/fedora  latest      a8accd4685fe  23 hours ago  318 MB
   

   result: the size of the image is listed as 318 MB

Sidenote:

I also did a test with --userns=auto and native overlay

podman pull -q registry.fedoraproject.org/fedora
for i in {0..9}; do
  podman run --rm --userns=auto --pull=never -d registry.fedoraproject.org/fedora sleep inf
done

The image size then increased roughly 10 times.

[jwcard]

Thank you! This does solve two problems. It solves the size problem and the time it takes to start up the first instance of the container. I tried to make the change to /etc/containers/storage.conf but that didn't seem to work but no big deal making the local change to the user config indeed resolves this issue.

…

On Fri, Oct 4, 2024 at 1:46 AM Erik Sjölund ***@***.***> wrote: An alternative solution is to use *fuse-overlayfs* instead of *native overlay* I listed the image size with podman images after running podman run --rm --userns=keep-id registry.fedoraproject.org/fedora /bin/true type image size after podman run --rm --userns=keep-id ... native overlay 636 Mb fuse-overlayfs 318 Mb Click to expand all the details of the tests native overlay 1. Create user *test1* sudo useradd test1 2. Open an interactive shell session for user *test1* sudo machinectl shell --uid=test1 3. Pull the image podman pull -q registry.fedoraproject.org/fedora 4. List images podman images The following output is printed REPOSITORY TAG IMAGE ID CREATED SIZEregistry.fedoraproject.org/fedora latest a8accd4685fe 23 hours ago 318 MB *result:* the size of the image is listed as *318 MB* 5. Run podman with --userns=keep-id podman run --rm --userns=keep-id registry.fedoraproject.org/fedora /bin/true 6. List images podman images The following output is printed REPOSITORY TAG IMAGE ID CREATED SIZEregistry.fedoraproject.org/fedora latest a8accd4685fe 23 hours ago 636 MB *result:* the size of the image is listed as *636 MB* fuse-overlayfs 1. Create user *test2* sudo useradd test2 2. Open an interactive shell session for user *test2* sudo machinectl shell --uid=test2 3. Create directory mkdir -p ~/.config/containers 4. Create the file *~/.config/containers/storage.conf* containing [storage] driver = "overlay" [storage.options.overlay] mount_program = "/usr/bin/fuse-overlayfs" 5. Pull the image podman pull -q registry.fedoraproject.org/fedora 6. List images podman images The following output is printed REPOSITORY TAG IMAGE ID CREATED SIZEregistry.fedoraproject.org/fedora latest a8accd4685fe 23 hours ago 318 MB *result:* the size of the image is listed as *318 MB* 7. Run podman with --userns=keep-id podman run --rm --userns=keep-id registry.fedoraproject.org/fedora /bin/true 8. List images podman images The following output is printed REPOSITORY TAG IMAGE ID CREATED SIZEregistry.fedoraproject.org/fedora latest a8accd4685fe 23 hours ago 318 MB *result:* the size of the image is listed as *318 MB* *Sidenote:* I also did a test with --userns=auto and *native overlay* podman pull -q registry.fedoraproject.org/fedora for i in {0..9}; do podman run --rm --userns=auto --pull=never -d registry.fedoraproject.org/fedora sleep inf done The image size then increased roughly 10 times. — Reply to this email directly, view it on GitHub <#24118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACI3UBX46W57OKPXKB25HLZZYTSRAVCNFSM6AAAAABPE4BK7CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOBUGAYTKNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>