[BUG] Over 1.4 gigabytes of extra storage used for docker image

[toddke]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

There is over 1.4 gigabytes in the writable layer of the home assistant docker image. This also means the total image size is over 1.4 gigabytes larger than it should be.

Either this change, aptly named "hail mary", or the original change, "chown system python packages" are the likely culprits.

Ideally, the python installation would not be modified at runtime. But, if there's no way around changing permissions at runtime, the docker image should not include python at all. Instead, install python during the first launch of the container. This would at least shrink the container by 1.4G and not cause /usr/local/lib/python to impact container size by double.

Expected Behavior

The image should not create a 1.5G writable layer.

Steps To Reproduce

1. Run the docker image
2. Look at the disk usage

   # docker ps -s --format 'table {{.Names}}\t{{.Image}}\t{{.Size}}' | grep homeassistant
   homeassistant          ghcr.io/linuxserver/homeassistant               1.48GB (virtual 3.17GB)
   

Environment

- OS: unRAID v6.12.14
- How docker service was installed: Community Applications plugin

CPU architecture

x86-64

Docker creation

Community Applications unRAID plugin

Container logs

N/A

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

The image size is not larger. The container layer is.

Anyhow, installing quite a bit more than a thousand python packages on container start is not a better solution.

I'm willing to review any PR that proposes a better solution to the problem at hand.

[toddke]

It'd only be the first time the container started, and it's better than consuming 1.4 gigabytes of space needlessly.

An alternate would be to chown only if the user/group was modified by the end user. What was the purpose of the hail mary change? Why did the original implementation of chown not work?

[aptalca]

Increased local storage space usage is a much lesser concern than increased bandwidth requirements, higher reliance on web connectivity (for thousands of dns queries and package downloads that significantly increase potential failure rate) and increased container start times (aka service downtime).

You can get a very decent 1tb nvme for about $70. 1.4gb is nothing these days.

Perms need to be fixed for HA to be able to install packages for HACS.

Chown on start causes the overlayfs bug for many, which results in operations taking upwards of 20 minutes to complete.

A move and chown operation prevents the bug, hence the current solution.

[toddke]

Depends upon your environment. 1.4G is significant in my setup, and probably others as well.

A slightly better approach combines the original implementation and the new one -- IFF the default group != docker group, copy and chown OTHERWISE create a link [hard or soft] from python.bak to python

Another, even simpler solution, could be to disallow the setting of USER/GROUP in the docker container.