Installing HA in docker on Ubuntu as non-root user

Installation
21

A quick note
I have created a test docker server and tested the run command … and it worked as it should.
I have also tested it with the docker-compose user: <your UID>:<your GID> and it also works.

So clearly something is not correct with the way my primary server’s permissions are configured.

1 Like
22

Please don’t forget that there is another issue with permission other than user config files.
docker run --user 999:999 trick works most of the time, but I just ran into a problem.

2019-06-10 00:25:27 ERROR (SyncWorker_13) [homeassistant.util.package] Unable to install package pybluez==0.22: ERROR: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: '/usr/local/lib/python3.7/site-packages/bluetooth'

homeassistant is trying to install into the container’s ‘/usr/local/lib/python3.7/site-packages/’ directory a new python module that was not included in the initial docker image. But because user 999 does not have a permission to write in ‘/usr/local/lib/python3.7/site-packages’, it fails miserably.

(I on Armbian arm64/v8 (Rock64, not Rpi3) and it seems ‘homeassistant/aarch64-homeassistant’ does not have a bluetooth module pre-installed)

I have run my homeassistant with user:homeassistant from day one. Not sure I should let it go.

Without a better user mapping scheme from the docker image builder, bye-bye non-root homeassistant!

1 Like
23

You’re totally right…I’ve kind of said bye to non-root home assistant for the same reason you presented, along with some others.

Is creating your own Dockerfile that has some non-root user configuration the only alternative?

1 Like
24

Also very interested in this. The python permission issue is tracked here: https://github.com/home-assistant/home-assistant/issues/24397

25

After some discussion ([1] [2]) I came up with this simple solution:

Please let me know if you have any problems.

1 Like
26

I just raised Issue #1 - HA onboarding fails because I got the dialogs:

  • Ah snap, something went wrong!
  • Something went wrong loading onboarding, try refreshing

when I tried to use it :frowning:

Your solution looked ideal, especially after those discussions with the core team. This is my first time with docker, migrating now from venv, and I’d really prefer to keep it in the user context rather than root. I do pre-create the folders, I’m not sure what direction to head now. I guess I need to learn about onboarding and that little file in the .storage folder,

27

Let’s continue the discussion on Github. You issues are probably due to your nginx config.

28

Thanks @tribut you were right that this error was a complete red herring – you solved my issue in nginx with your suggestion of proxy_set_header directives. Now HA in Docker with non-root user seems to be proceeding nicely!

1 Like
29

So far this tribut/homeassistant-docker-venv solution is working out nicely, many thanks @tribut. However I want to share a permissions issue I found, and the workaround.

In Docker running Home Assistant as non-root with this venv solution, I tried to configure ZHA. I could not get the comms to work to my HUSBZB-1 dongle (Z-wave & ZigBee combined). The errors included the following snippets

Error setting up entry /dev/ttyUSB1 for zha
PermissionError: [Errno 13] Permission denied: '/dev/ttyUSB1'
serial.serialutil.SerialException: [Errno 13] could not open port /dev/ttyUSB1: [Errno 13] Permission denied: '/dev/ttyUSB1'
  • the following workarounds failed:
    • sudo apt-get purge modemmanager
      • Package ‘modemmanager’ is not installed, so not removed
    • sudo usermod -a -G dialout $USER
      • no change
    • sudo lsof 2>/dev/null | grep ttyUSB
      • no processes using the device
    • docker-compose.yaml - privileged: true
      • no change in behaviour
  • the following diagnostics did not show anything suspicious
    • ls -l /dev/serial/by-id
    • ls -la /dev/ttyU*
      • do them both in docker exec too
    • udevadm info -a -n /dev/ttyUSB1 | grep ‘{interface}’ | head -n1
  • the following workaround succeeded, but did not persist a reboot
    • sudo chmod 0666 /dev/ttyUSB1

What worked for me was the following:

# get the Vendor and Product IDs from `lsusb`
sudo tee -a /etc/udev/rules.d/50-ttyusb.rules <<EOF!
KERNEL=="ttyUSB[0-9]*" \
, NAME="tts/USB%n" \
, SYMLINK+="%k" \
, ATTRS{idVendor}=="10c4" \
, ATTRS{idProduct}=="8a2a" \
, MODE="0666"
EOF!
2 Likes
30

Just wanted to add my thanks. Took me a few hours to come across this answer. I run dozens of docker containers and have fallen into the standard of setting UID/GID so that my files are sharable. This is the first time I have seen it not work.

Every time I upgrade Home Assistant I get more disappointed in the complexity in getting everything back working…

31

I haven’t update HA in a long time - one release quickly became 2 then 5 and now 30, so it became too much to keep track of all the breaking changes.

Anyway, looking to start fresh soon and was considering hassio in docker on Ubuntu.
Curious if this will work for this install method, or is this not an issue in that situation?
(I have not yet looked in to this at all, sorry for that.)

1 Like
32

The solution to run Hass Docker as non-root user using python venv is working.

Below another example of udev rules to allow the access of Phoscon Conbee ii inside a container. Same symptom as the one of @artmg got 4 months ago.

As root, create the file /etc/udev/rules.d/50-ttyacm.rules

KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", SUBSYSTEMS=="usb", SYMLINK+="%k", ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", MODE="0666"

To debug udev, arch linux documentation is really nice:
https://wiki.archlinux.org/index.php/Udev

@tribut thanks a lot for the venv idea. https://github.com/tribut/homeassistant-docker-venv

1 Like
33

Thank you for this. Giving root access to docker mounts is a big no-no for me as well (also running several other docker images - all of them use dedicated PUID and PGID. Definitely will give this a try!

34

@slaampit seems this will work only with Home Assistant core (not Hass.io) since Hass.io manages containers on it’s own.

35

I did not try hass.io yet as I’m using Arch linux as Operating System.
@sergred Was your try a success?

36

No, hass.io is virtual appliance which means you would need to literally fix every addon/node manually (because they all run in separate containers) and potentially do some fixes on every update. This is a loosing battle until all hass.io (and especially add-ons) community starts supporting it out of the box.

37

Thanks,
It confirms my choice to install home-assistant core manually.
Background: I prefer using yaml config than UI as it is easier to reuse, debug
(declarative vs imperative model)

38

Heads up:

It appears the Home Assistant docker image will start using s6 as init system (using s6-overlay):

This means the run-script from https://github.com/tribut/homeassistant-docker-venv will have to be modified. It should still be possible to run Home Assistant (Core) inside this new image as a non-privileged user, but we probably have to change the mount location to the Home Assistant “service directory” and modify the run-script to use the user-switching facilities of s6.

My tracking issue for this change is

3 Likes