Problem with file ownership in Homeassistant

Hello,

One of my homeassistant containers started to display an error with a custom integration because of a requirement not found. That integration recently bump a requirement for a python package and seems not be be able to install it any more.

I looked at the logs and when it tries to install the library/package, it cannot do so because it cannot write on /usr/local/lib/python3.12/site-packages. When I look at the ownership for that folder, the UID is 1001 and the GUID is 127.

Problem is that this is not the UID I passed to the container: I passed 1026, and that is indeed the UID of the abc user in the container. Now when I change the ownership of everything with a GID of 127 to 1026, it starts to work as intended.

I did not create an issue on github because I have no idea whether that’s a container problem or a me problem. I wonder if anyone has a similar issue, and if yes, is there something to change in the container build?

The following, as root, remediates the problem for me and I will set it up a custom init script as a workaround for the time being:

find /usr/local/lib/python3.12/site-packages/ -group 127 -exec chown abc '{}' \;

BTW: I chose an unrelated tag because discourse forced me to do so, and homeassistant was not in the list.

Hi, @xave.

I’m hitting a similar issue. The cause is almost certainly the changes checked into the docker-homeassistant project with tag 2024.10.2-ls34. Here’s the compare of that version against the previous version:

This change, which happened on Oct 12 introduced the “abc” user, added it to the lsio group, and used the lsio group to set permissions.

Does that coincide with when you started seeing your issue? Have you figured out any additional workarounds?

For me, this breaks the strategy I’ve been using to test ZHA quirks. I don’t have a workaround.

Please share your actual issue rather than your assumed diagnosis so we can avoid the xy issue.

abc user has been in this image since inception.

The lsio group was created in an attempt to mitigate an issue caused by an upstream change (switch to uv from pip). It didn’t fully work, so we implemented another change that seems to have fixed the issues with installing custom integration dependencies.

If you’re on the latest image and still experiencing an issue, please explain it in detail so we can look into it.

Thanks

Thanks for responding to this thread.

I’ll assume you have familiarity with Home Assistant (HA). If I refer to something for which you require additional clarification, please ask.

Zigbee Home Assistant (ZHA) supports a module called ZHA Quirks. Quirks is essentially a collection of device-specific drivers that allow these zigbee devices to participate in Home Assistant Automations.

When developing a new ZHA quirk, or modifying an existing one, it’s necessary to find a way to get the new quirk code to appear to be contained within the Home Assistant’s site packages directory. In the past, it has been possible to do this by using a specific volume mapping.

I am collaborating on an update to the Philips quirks, which enable Philips Hue devices to work with ZHA. To do this, I have a directory on my host machine at:

/volume1/docker/homeassistant/quirks_philips

To make this directory appear in the correct location with the container, I have historically been able to use a mapping in my yaml file as:

volumes:
  - /volume1/docker/homeassistant/quirks_philips:/usr/local/lib/python3.12/site-packages/zhaquirks/philips

That has worked for a long time but was broken by the change I referred to in my previous message. Specifically, this is the last version on which it works:

image: lscr.io/linuxserver/homeassistant:2024.10.2-ls34

My yaml file specifies my own PUID/PGID. I am an administrator and I am the owner of the quirks_philips folder.

To me, it looks like the change you made with the abc user didn’t take into account the potential for someone to need to map a directory into site_packages. My use case does require that.

I hope this makes sense. I’m happy to provide additional details. Thanks again for following up.

Fixed for me in 2024.10.3