Bluetooth in ubuntu 18.04 docker container

Configuration
,
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.

21

So today I needed to power down the electricity to do some work. I turned the power back on and when I went into HA and I was surprised to be greeted with a notification the the Bluetooth adapter was found and whether I wanted to configure it. Had to double check that the container didn’t have the privileged flag set.

I think this is down to me running commands on the host and the Bluetooth adapter then being locked to that host so wasn’t accessible to the container. I suspect I probably just needed to do something to release the adapter (I did think I had restarted all the bluetooth stuff) but if anyone else comes across this and has ran out of things to try then restarting to clear everything out might solve it…

22

This fixed my issue on a Raspberry Pi 4. HA could see my BLE device but would not setup/connect. It connected and worked without issue after installing dbus-broker.