Hartnäckiges Jessie RPi Problem "Can't open /dev/ttyAMA0: Keine Berechtigung"

[Qwz80]

Hallo,

seit meinem Raspberry Pi 2 Update auf Jessie habe ich das nervige "Can't open /dev/ttyAMA0: Keine Berechtigung" Problem.

Unter Wheezy war das Problem schnell behoben, aber jetzt ist nichts machbar.

Bisher probiert habe ich:

sudo usermod -a -G tty pi
sudo usermod -a -G tty fhem
cd /opt && sudo chmod -R a+w fhem
sudo adduser fhem dialout
sudo adduser pi dialout

Und auch das direkte Bearbeiten der Datei ttyAMA0 mit "sudo chmod o+rw /dev/ttyAMA0" bzw. mit a+x bringt nix. Nach einem Neustart sind die Rechte wieder wie vorher, oder besser gesagt werden gar nicht geändert, da FHEM immer noch sagt keine Berechtigung.

Langsam weiß ich echt nicht mehr weiter. Das Problem ist, dass ich mir jetzt einen echten CUL bestellt habe und befürchte, dass dieser nicht laufen wird, da eben die Rechte fehlen.

Ich weiß nicht ob der CUL sich unter /dev/serial/by-id/ meldet, denn darüber laufen meine beiden Selbstbau NanoCULs.

Also wenn einer weiß wie ich diese blöden Rechte da ändern kann.

[rumors]

Hi,

check mal ob dein CUL überhaupt auf AMA0 läuft.
Bei meinem PI2 ist das ACM0 ... danach kommt zwar noch der Probe auf AMA0 aber der CUL ist da bereits längst bei mir eingebunden

Code: [Auswählen]

2016.03.01 11:28:01 3: Probing CUL device /dev/ttyACM0
2016.03.01 11:28:01 1: define CUL_0 CUL /dev/ttyACM0@9600 ----
2016.03.01 11:28:01 3: Opening CUL_0 device /dev/ttyACM0
2016.03.01 11:28:01 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.03.01 11:28:01 3: CUL_0 device opened

2016.03.01 11:28:09 3: Probing CUL device /dev/ttyAMA0
2016.03.01 11:28:09 3: Can't open /dev/ttyAMA0: Permission denied

[Qwz80]

Ich habe den CUL von Busware noch nicht hier, sollte die Tage aber eintreffen. Ich habe unter /dev mur ttyAMA0 entdecken können.

Ich habe probeweise mal folgendes getestet. ArduinoNano mit CH340 Chip mit CULFW geflasht und versucht einzubinden. Mit define cultest CUL /dev/ttyAMA0@38400 0000 erwartungsgemäß nix. Discomnected.

Mit /dev/ttyUSB0@38400 0000 funktioniert es und wird als Initialized gelistet und funktioniert. Das klappt auch wenn ich den Arduino in einen anderen USB port stecke oder fhem neustarte.


Jetzt die Frage! Wenn ich dies AMA0 Problem nicht lösen kann, ist es möglich und sinnvoll den Busware Cul mit zb. Define Cul CUL /dev/ttyUSB0@9600 0000 einzubinden?

Oder gibt es dann irgendwann Probleme bei der Erkennung. Die Konfiguration des Raspberry bleibt jedenfalls so und wird nicht geändert. 

[Jostar]

Ich hatte das gleiche Problem. Ein Neustart des Pi hat dann CUL mit der richtigen tty... Adresse erkannt und FHEM direkt automatisch eingerichtet.

[Qwz80]

Ok Danke. Sobald der Busware CUL hier ist werde ich das ganze ausprobieren und hoffe, dass es läuft.

[errazzor]

Bei mir kommt dieser Fehler auch nach jedem Neustart, habe es auch nicht wegbekommen. Es läuft aber alles...

[Qwz80]

Lief wie beschrieben. Nach lesen des Wiki habe ich gesehen, dass der USB CUL immer auf ttyACMx gesetzt werden muss. ttyAMAx ist für den COC Einschub. Der CUL wurde jedemfalls nach dem flashen sofort erkannt und automatisch angelegt (ttyACM0).

[Prof. Dr. Peter Henning]

Suchen nach: "USB-Ports zuordnen".

LG

pah

[errazzor]

Ich habe nun endlich die Lösung für das Problem gefunden - zumindest bei mir. Ich weiss nicht, ob man das verallgemeinern kann, aber ich poste hier einfach mal meine Lösung.

Also mein CUL wird ja unter /dev/ttyACM0 eingehängt.

Trotzdem hatte auch ich immer den Fehler im Log:

Code: [Auswählen]

Can't open /dev/ttyAMA0: Permission denied

Die Verzeichnisrechte auf /opt für fhem waren korrekt gesetzt, trotzdem kam immer der Fehler.

Es lag daran, dass die Gruppe "tty" keine Leserechte auf das device ttyAMA0 hatte.

Wenn man sich z.b. folgende devices mal auflisten lässt:

Code: [Auswählen]

pi@raspberrypi ~ $ ls -lha /dev/ttyAMA0
crw--w---- 1 root tty 204, 64 Jun 12 01:26 /dev/ttyAMA0
pi@raspberrypi ~ $ ls -lha /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Jun 12 08:13 /dev/ttyACM0
pi@raspberrypi ~ $ ls -lha /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Jun 12 01:26 /dev/ttyUSB0
pi@raspberrypi ~

Hier sieht man...auf dem device ttyAMA0 fehlt im Gegensatz zu den beiden anderen aufgelisteten devices ein "r" (Leserecht) für die gruppe tty.
Ich habe das Leserecht hinzugefügt mit:

Code: [Auswählen]

sudo chmod g=rw /dev/ttyAMA0

...und seitdem ist der Fehler verschwunden. Im Log tauchen nun diese drei Einträge auf:

Code: [Auswählen]

2016.06.12 01:26:50 3: Probing CUL device /dev/ttyAMA0
2016.06.12 01:26:51 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.06.12 01:26:51 3: Probing FRM device /dev/ttyAMA0
2016.06.12 01:26:56 1: usb create end

Also kein Fehler mehr.

Das einzige was ich wirklich nicht verstehe an der ganzen Sache ist die logische Ursache für das ganze.

Denn schaut man sich die Berechtigungen mal genauer an, kommt man zu folgendem Ergebnis:

Code: [Auswählen]

pi@raspberrypi ~ $ ls -lha /dev/ttyAMA0
crw--w---- 1 root tty 204, 64 Jun 12 01:26 /dev/ttyAMA0
pi@raspberrypi ~ $ ls -lha /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Jun 12 08:13 /dev/ttyACM0
pi@raspberrypi ~ $ ls -lha /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Jun 12 01:26 /dev/ttyUSB0
pi@raspberrypi ~

Wie zu sehen ist, ist der BESITZER der drei Dateien immer root.

Die berechtigte Gruppe für das device "ttyAMA0" ist tty.
Die berechtigte Gruppe für die Devices ttyACM0 und ttyUSB0 ist "dialout".

Für "sonstige" sind keinerlei Rechte gesetzt. Folglich haben also nur root und die jeweils eingetragene Gruppe Rechte auf das device.

Schaut man sich jetzt aber mal die Gruppenmitgliedschaften an...

Code: [Auswählen]

pi@raspberrypi ~ $ grep dialout /etc/group
dialout:x:20:pi
pi@raspberrypi ~ $ grep tty /etc/group
tty:x:5:pi,fhem

...so sieht man, dass "fhem" lediglich Mitglied der Gruppe "tty" ist. Die Gruppe "tty" hatte kein Leserecht auf das device, deshalb der Fehler, soweit nachvollziehbar.

"fhem" ist aber *nicht* Mitglied der Gruppe "dialout" ... also hätte nach meinem Verständnis der Fehler eigentlich auch bei den anderen beiden Devices auftreten müssen...nach meinem Verständnis hat "fhem"
kein Leserecht auf die beiden devices...trotzdem kommt kein Fehler.

Kann mir das jemand erklären, warum es sich so verhält?

[Kawaci]

hatte das letztens mit deiner Datei, habe auf fb in der Gruppe gefragt und da hab ich es mit

Code: [Auswählen]

chown fhem /code][code]
gelöst!

also

Code: [Auswählen]

chown fhem /dev/ttyAMA0[code]
versuch mal!

[steffen@hexmex.de]

Da dieser Beitrag ganz gut mein aktuelles Problem beschreibt, würde ich hier gerne noch eine Beobachtung hinzufügen, die ich beim Aufsetzen FHEM auf Raspberry PI3 mit Betriebssystem Version Jessi und Nutzung von CC1101 im Januar 2017 gemacht habe. Jessi für PI3 habe ich aus dem Internet frisch geholt.

Ich habe die Einstellungen, wie in https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth|FHEm-Wiki beschrieben, vorgenommen und kann auch das Blinken der LED ein- und ausschalten. fhem hat jedoch das in diesem Beitrag beschriebene Rechteproblem mit der /dev/ttyAMAO.
 
Bei mir hilft allerdings das Setzen des Leserechts für die Gruppe tty für ttyAMA0  (Als User pi folgenden Befehl eingegeben: sudo chmod g+r /dev/ttyAMA0) nur kurzzeitig. Bei laufendem fhem setzt irgend etwas nach wenigen Augenblicken (< 3 Minuten) wieder den Ursprungszustand zurück (also entfernen des Leserechts für die Gruppe tty). Auch das Verschenken der Datei an den User fhem (sudo chown fhem /dev/ttyAMA0) hat den selben Effekt (Rückgabe der Datei an root).

Ich habe dann das Recht ohne laufendes fhem geändert. 20 Minuten später war es noch nicht wieder zurückgesetzt. Auch nach einem Reboot behält tty das Leserecht.
 
Da die Rechte nur durch den root oder unter Verwendung von sudo geändert werden dürfen und mein fhem User den sudo nicht einsetzen darf (sicherheitshalber auch noch mal getestet), vermute ich, das hier auf Betriebssystemebene etwas als root arbeitet, welches bei Nutzung der Schnittstelle die Rechte wieder zurücksetzt.

Um dieses weiter zu analysieren, fehlen mir aber leider die nötigen Linux Kenntnisse und auch stundenlanges Suchen im Internet hat nicht weiter geholfen. Ich werde mein fhem daher jetzt auf Betriebssystemversion Wheezy aufsetzen. Das ist für mich nur eine bedingt gute Lösung (denn alles entwickelt sich ja weiter und hier steht jetzt für mich ein Stopp Schild beim Einsatz von CC1101) und wenn jemand eine Idee hat, wie die Ursache behoben werden kann,  würde ich gerne wieder einen Versuch mit Jessi starten.

[Otto123]

Das ist aber längst gelöst.

In der Datei /boot/cmdline.txt diesen Eintrag löschen:

console=serial0,115200
Den Dienst serial-getty deaktivieren

systemctl disable serial-getty@ttyAMA0.service

Der Benutzer fhem muss Mitglied in der Gruppe dialout sein! Bitte kontrollieren.

Gruß Otto

[steffen@hexmex.de]

Hallo Otto,

vielen Dank, das Du nochmal auf das Entfernen von console=serial0,115200 hingewiesen hast. Ich hatte das schon mehrfach gemacht und war daher äußert erstaunt, das ich den Eintrag heute Mittag wieder vorgefunden habe.
Inzwischen habe ich rausgefunden, das dieser erzeugt wird, wenn man nach Aufruf von sudo raspi-config die seriellen Interface aktiviert.

Habe dann den Eintrag also erneut entfernt, den Dienst serial-getty deaktiviert und dann neu gebootet. Der Spuck mit dem Rücksetzen der Rechte war jetzt weg, aber fhem weigerte sich weiterhin, die Verbindung herzustellen.
Die Lösung bei mir war, das der User fhem nicht der Gruppe gpio zugeordnet war. Herausgefunden habe ich diese, in dem ich mit dem fhem User die Befehle zum schalten der LED auf dem CUL aufgerufen habe (echo out > /sys/class/gpio/gpio17/direction  und  echo 0 > /sys/class/gpio/gpio17/value) . Hier bekam ich ein Permission denied. Nach dem Zuordnen der Gruppe mit sudo usermod -a -G gpio fhem hat fhem dann den Connect herstellen können.

Ach ja, wenn jemand mal bei sudo ls -l /sys/class/gpio/gpio17/direction feststellt, das die Datei auch der Gruppe root gehört, liegt das evtl. daran, das in der Datei /etc/udev/rules.d/99-com.rules die nachfolgenden Zeilen auskommentiert sind oder entfernt wurden (hatte einen Hinweis im Internet gefunden, bei dem das als Lösungsansatz für ein Problem mit der gpio Schnittstelle beschrieben wurde):

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
        chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
        chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
        chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
'"

[steffen@hexmex.de]

Leider zu früh gefreut. CUL ist Connected, STACKABLE_CC_1 Defined aber es gehen keine Signale an Schalter und von den Sensoren kommt auch nichts rein.
Beim reopen im Verbose-Modus 5 erscheint immer noch eine Zeile Cannot init /dev/ttyAMA0, ignoring it (CunoErstesOG_)

Der gesamte Auszug lautet:

Code: [Auswählen]

2017.02.04 11:42:54 4: FHEMWEB:192.168.0.134:14618 POST /fhem&detail=CunoErstesOG_&dev.setCunoErstesOG_=CunoErstesOG_&cmd.setCunoErstesOG_=set&arg.setCunoErstesOG_=reopen&val.setCunoErstesOG_=; BUFLEN:0
2017.02.04 11:42:54 5: Cmd: >set CunoErstesOG_ reopen<
2017.02.04 11:42:54 3: Setting CunoErstesOG_ serial parameters to 38400,8,N,1
2017.02.04 11:42:54 1: /dev/ttyAMA0 reappeared (CunoErstesOG_)
2017.02.04 11:42:54 5: SW: V
2017.02.04 11:42:57 5: SW: V
2017.02.04 11:43:00 5: SW: V
2017.02.04 11:43:03 1: Cannot init /dev/ttyAMA0, ignoring it (CunoErstesOG_)
2017.02.04 11:43:03 5: Triggering CunoErstesOG_ (1 changes)
2017.02.04 11:43:03 5: Notify loop for CunoErstesOG_ CONNECTED
2017.02.04 11:43:04 5: SW: *V
2017.02.04 11:43:04 5: Triggering STACKABLE_CC_1 (1 changes)
2017.02.04 11:43:04 5: Notify loop for STACKABLE_CC_1 CONNECTED
2017.02.04 11:43:04 4: FHEMWEB:192.168.0.134:14618 GET /fhem?detail=CunoErstesOG_; BUFLEN:0
2017.02.04 11:43:04 4: name: /fhem?detail=CunoErstesOG_ / RL:3817 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2017.02.04 11:43:05 4: FHEMWEB:192.168.0.134:14618 GET /fhem?cmd={ReadingsVal(%22CunoErstesOG_%22,%22bWidth%22,%22%22)}&XHR=1; BUFLEN:0
2017.02.04 11:43:05 5: Cmd: >{ReadingsVal("CunoErstesOG_","bWidth","")}<
2017.02.04 11:43:05 4: name: /fhem?cmd={ReadingsVal(%22CunoErstesOG_%22,%22bWidth%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2017.02.04 11:43:05 4: Connection accepted from FHEMWEB:192.168.0.134:14619
2017.02.04 11:43:05 4: FHEMWEB:192.168.0.134:14618 GET /fhem?cmd={AttrVal(%22CunoErstesOG_%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2017.02.04 11:43:05 5: Cmd: >{AttrVal("CunoErstesOG_","room","")}<
2017.02.04 11:43:05 4: name: /fhem?cmd={AttrVal(%22CunoErstesOG_%22,%22room%22,%22%22)}&XHR=1 / RL:34 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2017.02.04 11:43:05 4: FHEMWEB:192.168.0.134:14618 GET /fhem?XHR=1&inform=type=status;filter=CunoErstesOG_;since=1486204983;fmt=JSON&timestamp=1486204971992; BUFLEN:0
2017.02.04 11:43:10 4: Connection closed for FHEMWEB:192.168.0.134:14619: EOF


In einem anderen Beitrag (https://forum.fhem.de/index.php?topic=55392.0) lag die Lösung darin, in der /boot/config.txt den Eintrag dtoverlay=pi3-disable-bt und anschließendem enable_uart=1 zu verwenden.
Der Austausch meines dtoverlay=pi3-miniuart-bt (enable_uart=1 hatte ich schon gesetzt zusammen mit einem force_turbo=1) hat leider nichts geändert.

Hat jemand eine Idee, was noch nicht paßt bzw. was ich noch prüfen und ausprobieren kann?

[Otto123]

Hi,

Du musst einfach die serielle Schnittstelle ordentlich konfigurieren, da gibt es nicht viel zu "probieren".

z.B. so -> https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Vorbereitung_serielle_Schnittstelle_unter_Jessie

Gruß Otto