Bluetooth in ubuntu 18.04 docker container

Configuration
,
1

Doing my head in here :smile: and I suspect that this is something that someone else might have dealt with.

Home Assistant running in a python virtual environment (not in docker) can see the intel nuc bluetooth device on hici0 fine (bluez version 5.64). When running in docker with --privileged, also no problem. However, I would like a docker environment that doesn’t run as root, with total access to the OS - my system is internet facing after all.

So I have followed the instructions here (improve docker security) and here (HA non-root user) to arrive at this docker compose config:

    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /opt/homeassistant:/config
      - /etc/localtime:/etc/localtime:ro
      - /opt/homeassistant/docker/run:/etc/services.d/home-assistant/run
      - /run/dbus:/run/dbus:ro
    environment:
      - TZ=Europe/London
      - PUID=998
      - PGID=998
      - UMASK=007
      - PACKAGES=iputils
    security_opt:
      - no-new-privileges
    cap_add:
      - NET_RAW
      - NET_ADMIN
      - SYS_ADMIN
    restart: unless-stopped
    network_mode: host

Home Assistant is running fine as a non-root user, but still can’t see the bluetooth controller. Here is the error that is generated:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/bluetooth_adapters/dbus.py", line 97, in _get_dbus_managed_objects
    reply = await bus.call(msg)
  File "/usr/local/lib/python3.10/site-packages/dbus_fast/aio/message_bus.py", line 358, in call
    await future
  File "/usr/local/lib/python3.10/site-packages/dbus_fast/aio/message_bus.py", line 426, in _message_reader
    if unmarshaller.unmarshall():
  File "src/dbus_fast/_private/unmarshaller.py", line 416, in dbus_fast._private.unmarshaller.Unmarshaller.unmarshall
  File "src/dbus_fast/_private/unmarshaller.py", line 425, in dbus_fast._private.unmarshaller.Unmarshaller.unmarshall
  File "src/dbus_fast/_private/unmarshaller.py", line 357, in dbus_fast._private.unmarshaller.Unmarshaller._read_header
  File "src/dbus_fast/_private/unmarshaller.py", line 232, in dbus_fast._private.unmarshaller.Unmarshaller.read_to_pos
EOFError

I’ve tried disabling bluetooth and dbus on the host in case there were conflicts. No joy.

Anyone? Please! Before I do something I might regret. :rofl: :

1 Like
2

If not root user the user must have access to dialout or serial or some other device permissions.

EDIT
Devices group permissions

3

Yes the user id 998 maps to the host user ‘homeassistant’ who is a member of the bluetooth group and can access hci0 in the host environment. In the docker, as user homeassistant, I get this when running bluetoothctl:

bash-5.1$ id
uid=998(homeassistant) gid=998(homeassistant) groups=998(homeassistant)
bash-5.1$ ls /run/dbus
system_bus_socket
bash-5.1$ bluetoothctl
Waiting to connect to bluetoothd...dbus[179]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5921.
This is normally a bug in some application using the D-Bus library.

  D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted (core dumped)
bash-5.1$
4

Still going at this - I think there must be a problem between differing versions of bluez on the host and container. Here is the container:

bash-5.1# cat /etc/*ease
3.16.0
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.16.0
PRETTY_NAME="Alpine Linux v3.16"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
bash-5.1# hcitool dev
Devices:
        hci0    B4:D5:BD:F4:D0:34
bash-5.1# bluetoothctl --version
bluetoothctl: 5.65
bash-5.1# bluetoothctl
Waiting to connect to bluetoothd...dbus[182]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5921.
This is normally a bug in some application using the D-Bus library.

  D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted (core dumped)
bash-5.1#

And the host:

andrew@haserver:~$ cat /etc/*ease
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.6 LTS"
NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
andrew@haserver:~$ hcitool dev
Devices:
        hci0    B4:D5:BD:F4:D0:34
andrew@haserver:~$ bluetoothctl --version
bluetoothctl: 5.48
andrew@haserver:~$ bluetoothctl
[NEW] Controller B4:D5:BD:F4:D0:34 haserver [default]
Agent registered
[bluetooth]# quit
Agent unregistered
[DEL] Controller B4:D5:BD:F4:D0:34 haserver [default]
andrew@haserver:~$
5

I thought it works with root user?
Are you saying one version of bluez requires root? Why you think changing user make difference?

Did you change HA version when change user? Try older HA version.

6

Going round in circles!! So after a break, some more testing. It isn’t anything to do with bluez versions. I have bluez 5.65 in the container and 5.48 on the host. As soon as I enable privileged mode for the container, bluetooth works (with HA running in a virtual environment as a standard user within the container). Without it, bluetooth fails, even with the added capabilities (NET_RAW_, NET_ADMIN and SYS_ADMIN) applied to the docker and the python binary in the container.

So it is definitely still a permissions thing.

7

I’m having this exact issues, Ubuntu Intel NUC 10, i’m getting the same errors from the container (dbus exposed via a volume), host is fully functional. I think you’re right feels like a permissions issue at this point.

Edit: Are you running your container in Privileged mode?

8

Privelege work because it’s root

Goal is non root user

9

Got it - will follow this thread, also was having issues that were resolved after moving to priviledged mode.

10

I have followed this article (How to run containerized Bluetooth applications with BlueZ | by Thomas Huffert | omi-uulm | Medium) which seemed very thorough, but cannot get a working solution. This is with containers based on both alpine and ubuntu. They work fine as long as privileged mode is enabled, but as soon as you disable that, they fail. Honestly completely stuck with it.

The crazy thing is that I can access the device hci0 in unprivileged mode using hciconfig, but get errors when I try and run bluetoothctl.

11

Have you found out the solution for the problem? I have the same exact versions of bluez like you but also the same issues. privileged mode works fine but don’t really wanna run it on that 247.

But I have a 22 Ubuntu server with container

12

The solution I thought I had was to use an esphome Bluetooth proxy, but unfortunately even that isn’t working properly yet. Still some way to go before home assistant and Bluetooth work smoothly for me at least.

13

!!Disclaimer!!
I’ve been sitting on this problem the whole day, and I tried a ton of things which I have no idea of and never restarted the host system (my server) so it might have been something else, but I highly think it is this one,
I wish you success :slight_smile:
!!Disclaimer!!
Okay Okay, I found the solution for me!!! without privilied. It’s the dbus broker.

The Bluetooth Doc in HA doc also hints to it. You need to install that on the host and restart the host. I used following commands on my Ubuntu 22 server

sudo apt install dbus-broker

#than
sudo systemctl enable dbus-broker.service

#followed by
systemctl --global enable dbus-broker.service

#Restart Host
sudo reboot

Restart the System and the Bluetooth Dev instantly showed up in HA.
Make sure you did the obvious things like rounting your /run/dbus and network set to host.

Please tell me if it worked :smiley:

2 Likes
14

I have tried this on Ubuntu 18.04 and no joy. dbus broker is running fine and I can use the bluetooth device on the host, just not in the container. I wonder if it is something that 20.04 or even 22.04 has improved?

15

I have no answer to that, if you have tried everything might aswell try that :smiley:

16

Same problem tried your suggestion but that didn’t work unfortunately

17

I had a hell of a time getting the ASUS USB-BT500 working in a Home Assistant docker container, but I got it. This is going to be less of guide and more of a list of the crap I threw at the wall to get it to work.

Grabbed the driver from ASUS’s site, unzipped, and followed the directions to install, notably
sudo make install INTERFACE=usb

bluetoothctl would work on the host machine, but in the container I’d get

arguments to dbus_connection_get_object_path_data() were incorrect  
...  
Aborted (core dumped)

lsusb was able to list the bus and device of the bt500. which I added to the docker-compose.

docker-compose.yml
    volumes:
      - /var/run/dbus:/var/run/dbus
    devices:
      - /dev/bus/usb/005/001:/dev/ttyBT

After that, bluetoothctl would work in the container, and Home Assistant recognized the device properly.

This reddit post was the last one in the many threads and comments I read trying to get this working. Thanks for the hints, /u/FreeSoftwareServers.

18

I thought this was the answer to my issues but close but not close enough…
I have a new Intel N100 PC with the onboard Intel AX Wifi / Bluetooth.

I am running HA via doicker on Ububtu 23.04 (Lunar Lobster)

I got the Bluetooth working on the host

sudo su -
cd /lib/firmware/intel/
ln -s ibt-1040-4150.ddc ibt-0040-1050.ddc
ln -s ibt-1040-4150.sfi ibt-0040-1050.sfi

then

sudo apt-get install bluez
sudo apt-get install dbus-broker
sudo systemctl enable dbus-broker.service

which then brought it all to life and bluetoothctl shows up the controller and I can scan and see devices finer.

In HA however bluetoothctl just dies with the

Waiting to connect to bluetoothd...dbus[329]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5969.
This is normally a bug in some application using the D-Bus library.

  D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted (core dumped)

error

I have mapped through /run/dbus and attempted lots of different approaches at mapping the device, (It doesn’t seem be a tty device but I can get the USB details from lsusb. The major device type shows up as 189 rather than 188 for a standard device and I can see locally that there is a symlink from /dev/char/189:2 to /dev//bus/usb/001/003 (which is what shows up with lsusb)

The Linux docs have major type 189 down as

189 char USB serial converters - alternate devices
0 = /dev/cuusb0 Callout device for ttyUSB0
1 = /dev/cuusb1 Callout device for ttyUSB1
…
but thhere are not /dev/cuusb* devices listed on the host.

If I run the container in privileged mode then all is fine and HA recognises the device but I don’t want to run in privileged mode…

Tearing my hair out on this. The error is the same if you map no device at all so I am wondering whether I just need to find the magic device name to map across or whether there is something more fundamental I need to try ??? Any ideas???

19

Sounds like permission problem. I had similar problems when running container as non-root user. Does user have correct permissions?

20

The container user is root.