[Gelöst] Nach Umzug auf Docker wird ttyACM0 nicht mehr gefunden

[HankMoody]

Guten Abend zusammen,

ich hatte fhem bisher auf einem Raspi 3 mit CUL_MAX am laufen und es funktioniert auch alles damit.
Nun wollte ich auf Docker umsteigen und meine Config mitnehmen. Und zwar mit dem offiziellen Docker-Image von fhem auf einer frischen SD-Karte/Installation.

Allerdings bekomme ich nun folgende Fehlermeldung im Log:

Code Auswählen Erweitern

CUL0: Can't open /dev/ttyACM0: No such file or directory

Hier mal meine Vorgehensweise beim Umzug auf Docker. Dazu ist allgemein wenig zu finden, wie man es am besten macht:

Ich habe in der alten fhem-Installation ein Backup über die fhem-Oberfläche gemacht und mir die .tar.gz per SCP auf den PC gesichert.

Nun auf der neuen SD-Karte mit Raspberry Pi OS Docker installiert und das fhem/fhem-Image gezogen.

Dann habe ich den Container mit folgendem Befehl gestartet:

Code Auswählen Erweitern

docker run -d --name fhem -p 8083:8083 -v opt-fhem:/opt/fhem fhem/fhem --device=/dev/ttyACM0

Den Zugriff auf /dev/ttyACM0 hatte ich vorher mit screen geprüft im Raspi-Host-System.

Nachdem fhem fertig gestartet war und seine Installation in mein Volume opt-fhem geschrieben hatte, war auf der Webseite die Default-Config sichtbar.

Als nächstes stoppte ich den Container mit "docker stop fhem" und entpackte mein altes Backup in das Volume-Verzeichnis um die Default-Installation mit meiner alten Installation zu erweitern:

Code Auswählen Erweitern

sudo tar -xzf FHEM-20201018_213925.tar.gz -C /var/lib/docker/volumes/opt-fhem/_data/

Nachdem ich den Container wieder per "docker start fhem" gestartet hatte war meine alte Config mit all meinen eingerichteten Geräten auf der Oberfläche zu sehen. Im Logfile kamen allerdings folgende Fehlermeldungen:

Code Auswählen Erweitern


2020.10.19 21:02:57 3: Opening CUL0 device /dev/ttyACM0
2020.10.19 21:02:57 1: CUL0: Can't open /dev/ttyACM0: No such file or directory
2020.10.19 21:02:57 2: Switched CUL0 rfmode to MAX
2020.10.19 21:02:57 1: CUL_MAX_Check: No IODev has no VERSION
2020.10.19 21:02:57 3: CUL_MAX_Check: Detected firmware version 0 of the CUL-compatible IODev
.....
2020.10.19 21:03:32 1: CUL_MAX_Check: No IODev has no VERSION
2020.10.19 21:03:32 1: Error in CUL_MAX_SendQueueHandler: CUL CUL0 did not answer request for current credits.


Was ich daraufhin noch probiert habe:
-Update von fhem über die Oberfläche
-Anlegen des Users und der Gruppe fhem mit der UID:GID 6061. Diese ID hat der User, unter dem fhem im Container/Image läuft. Zumindest werden die Dateien im Volume mit diesen Rechten angelegt bzw. darauf geändert. Zusätzlich habe ich den User fhem in die Gruppe dialout aufgenommen.
Mit folgenden Befehlen:

Code Auswählen Erweitern


sudo groupadd -g 6061 fhem
sudo useradd -M -u 6061 -g 6061 -s /bin/false -G dialout fhem


Dies hat beides nichts geholfen.

Hat jemand eine Idee was ich falsch mache?

Viele Grüße
Roman

[Wernieman]

Hast Du mal in den Container geguckt?

Also mit "docker exec -it <Containername> /bin/bash" reinhüpfen und dort nach dem Device "sehen"

[HankMoody]

Ein "ls -al /dev/" im Container zeigt folgendes:

Code Auswählen Erweitern


total 4
drwxr-xr-x 5 root root  320 Okt 20 18:58 .
drwxr-xr-x 1 root root 4096 Okt 20 18:58 ..
lrwxrwxrwx 1 root root   13 Okt 20 18:58 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Okt 20 18:58 full
drwxrwxrwt 2 root root   40 Okt 20 18:58 mqueue
crw-rw-rw- 1 root root 1, 3 Okt 20 18:58 null
lrwxrwxrwx 1 root root    8 Okt 20 18:58 ptmx -> pts/ptmx
drwxr-xr-x 2 root root    0 Okt 20 18:58 pts
crw-rw-rw- 1 root root 1, 8 Okt 20 18:58 random
drwxrwxrwt 2 root root   40 Okt 20 18:58 shm
lrwxrwxrwx 1 root root   15 Okt 20 18:58 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root   15 Okt 20 18:58 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root   15 Okt 20 18:58 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root tty  5, 0 Okt 20 18:58 tty
crw-rw-rw- 1 root root 1, 9 Okt 20 18:58 urandom
crw-rw-rw- 1 root root 1, 5 Okt 20 18:58 zero



Auf dem Raspi-Host, also außerhalb des Containers, findet er das Device mit folgenden Details:

Code Auswählen Erweitern


pi@raspberrypi:~ $ ll /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Okt 19 22:30 /dev/ttyACM0


[Wzut]

Ich habe zwar Null Ahnung von Docker , aber schau dir doch mal die Seite an : https://github.com/OctoPrint/octoprint-docker/issues/7
Die haben eigentlich das gleiche Problem & Lösung, denn ob der User nun octoprint oder fhem ist , die Gruppe dialout nutzen beide.
Und die Udev Rule solltest auch leicht auf deinen CUL übertragen können. Schau dort mal im ersten Post, der bindet seine Schnittstelle mit --device /dev/ttyACM0:/dev/ttyACM0 , k.A. ob das zu deiner kurzen Version einen Unterschied macht. 

[HankMoody]

Hallo Wzut,

danke für den Link. Der Fragesteller auf der Seite hat ja das Problem "Permission denied", vorhanden ist das Device bei ihm aber. Bei mir ist es allerdings gar nicht vorhanden im Container.

Den Parameter "--privileged" habe ich auch schon probiert, hat nichts geändert. Allerdings würde ich den auch lieber vermeiden wollen, sonst bringt ja der ganze Container nichts wenn er eh auf alles zugreifen kann. Der Parameter "--device" soll ja nur einzelne Devices in den Container hineinreichen.

Und das mit der Gruppe "dialout" hatte ich ja schon probiert.

Mich wundert es, dass ich wohl der einzige bin mit diesem Problem. Oder der einzige, der fhem in Docker laufen lässt. Die meisten werden wohl irgend einen USB-Adapter mit fhem verwenden, wie CUL, JeeLink usw. Mein Use-Case sollte daher eigtl. häufig sein, also USB-Adapter in den Container mappen 

[HankMoody]

Folgenden nützlichen Link habe ich noch gefunden:
http://marc.merlins.org/perso/linux/post_2018-12-20_Accessing-USB-Devices-In-Docker-_ttyUSB0_-dev-bus-usb-_-for-fastboot_-adb_-without-using-privileged.html

Daraufhin habe noch folgende Befehlzeile zum Erstellen/Starten meines Containers probiert:

Code Auswählen Erweitern

docker run -d --name fhem -p 8083:8083 -v opt-fhem:/opt/fhem fhem/fhem --device=/dev/bus/usb/001/004 -v /dev/ttyACM0:/dev/ttyACM0

Dies hat allerdings auch nichts geändert.

Den Bus+ID habe ich über folgenden Befehl herausfinden können:

Code Auswählen Erweitern

lsusb -v | grep -E '\<(Bus|iProduct|bDeviceClass|bDeviceProtocol)' 2>/dev/null

Den habe ich von der Doku des fhem-Containers:
https://github.com/fhem/fhem-docker

[HankMoody]

"lsusb" im Container zeigt mir übrigens die gleichen 4 Geräte an, die ich auch außerhalb auf dem Host habe. Der erste sollte mein CUL sein:

Code Auswählen Erweitern


Bus 001 Device 004: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


[HankMoody]

So, ich habe die Lösung des Problems gefunden.

Ich hatte es noch mit dem debian:buster-Image probiert, auf dem das fhem-Image ja basiert, mit dem gleichen Device-Parameter:

Code Auswählen Erweitern

docker run -dit --name debian-test debian:buster --device=/dev/ttyACM0

Dies bringt dann folgende hilfreiche Fehlermeldung:

Code Auswählen Erweitern

docker: Error response from daemon: OCI runtime create failed: container_linux.go:344: starting container process caused "exec: \"--device=/dev/ttyACM0\": stat --device=/dev/ttyACM0: no such file or directory": unknown.

Es müssen also die beim Docker run-Befehl zuerst die Optionen, danach der Image-Name und zuletzt ein optionaler Befehl zum Starten (exec) angeben werden.

Wenn ich den Befehl aus meinem ersten Post folgendermaßen umstelle, dann funktioniert es mit dem fhem-Image:

Code Auswählen Erweitern

docker run -d --name fhem -p 8083:8083 -v opt-fhem:/opt/fhem --device=/dev/ttyACM0 fhem/fhem

Kaum macht mans richtig, schon geht's 

Danke für eure Hilfe!