Posts by androbey

    Ich kann das Verhalten, das asdfjweurio auch hat, nur nochmal bestätigen.
    Ich habe bei einem Pi ein Downgrade auf 5.10.17 durchgeführt (Zugriff usw. funktioniert problemlos) und nun mit rpi-update auf die neueste Firmware aktualisiert (5.10.52-v7l+ #1444 SMP Thu Aug 12 20:23:40 BST 2021 armv7l GNU/Linux). Dort funktioniert es weiterhin nicht.

    Auch von mir mal die Ausgabe:


    Code
    ls -lisa /media/fritzbox
    insgesamt 4
       560 0 drwxr-xr-x 2 pi   pi      0 Sep 24  2019 .
    915713 4 drwxr-xr-x 5 root root 4096 Sep  3  2020 ..
       635 0 drwxr-xr-x 2 pi   pi      0 Aug 7 20:30 faxbox
       562 0 drwxr-xr-x 2 pi   pi      0 Aug 11 21:07 mediabox
       561 0 drwxr-xr-x 2 pi   pi      0 Jan  1  1970 voicebox


    Übrigens mount zeigt bei mir in Bezug auf den mount des Fritzbox NAS und abgesehen vom Benutzer genau das gleiche wie bei Franjo G


    Code
    ... uid=1000,forceuid,gid=1000,forcegid,addr=192.168.178.1,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1)

    Zur Vollständigkeit auch hier. Ein Downgrade auf Firmware Version 5.10.17 hat bei mir die Probleme vorerst behoben (d.h. damit klappt wieder alles einwandfrei). Das ist aber natürlich keine Lösung für das eigentliche Problem, warum es bei der aktuellen Firmware nicht mehr klappt.

    Ich hab exakt das gleiche Problem an zwei verschiedenen Pis. Es liegt nicht am Kernel, den hab ich versuchsweise wieder auf 5.10.38 zurückgedreht.

    Aber seit dem letzten apt-upgrade wurden auch die Pakete "libgssapi-krb5-2, libk5crypto3, libkrb5-3, libkrb5support0" aktualisiert, bei denen ich einen Zusammenhang vermute.


    Konntest du mittlerweile näheres herausfinden?

    Ich denke tatsächlich, dass es am Kernel liegt (oder einer Kombination aus Kernel und anderen Paketen). Ich habe bei einem Pi ein Downgrade auf 5.10.17 durchgeführt (das ist vom Februar 2021), damit funktioniert es wieder problemlos.

    Das stand alles am Bildschirm, und Du hast die Rückfragen mit n oder y beantwortet.

    Das stimmt natürlich. Ich weiß auch welche Pakete aktualisiert wurden, nur kann ich bei keinem einen direkten Zusammenhang dazu herstellen, wie sich das auf das Einbinden des NAS auswirkt (aktualisiert wurde z.B. raspberrypi-kernel und raspberrypi-bootloader). In man mount.cifs konnte ich auch nichts finden, was für die beiden betreffenden Kernel Versionen relevant ist.

    Danke soweit für die Hilfe!

    Fuer mich ist das ein grosser Unterschied und kann Probleme erzeugen.Ist zwar selten - aber es kommt vor.

    Dass ich vermutlich selbst dran schuld bin, dass es jetzt nicht funktioniert ist mir bewusst. Ich habe bei einem der beiden Raspberry auch ein Backup eingespielt, da klappt es wieder ohne Probleme. Beim zweiten gibt leider kein aktuelles Backup.

    Ergebnis nach umount:


    Code
    ls -al /media/fritzbox
    insgesamt 8
    drwxr-xr-x 2 root root 4096 Jul 29  2020 .
    drwxr-xr-x 5 root root 4096 Sep  3  2020 ..


    Das zeigt df wenn der mount Befehl ausgeführt wurde (also bei eigentlich eingehängtem NAS):


    Code
    Dateisystem                      1K-Blöcke  Benutzt Verfügbar Verw% Eingehängt auf
    //192.168.178.1/FRITZ.NAS/FRITZ/    353116      692    352424    1% /media/fritzbox


    Ich habe das ganze mit manuellen cifs mount ausprobiert (sowohl mit Versionsangabe, als auch ohne und außerdem mit verschiedenen sec Parameter-Optionen). Auch die Angabe eines verbose flags beim cifs mount Befehl bringt keine Erkenntnisse hervor.

    Ich konnte aber leider auch nicht herausfinden, ob bzw. was sich geändert haben könnte beim upgrade. Vor dem Upgrade hat alles ohne Probleme funktioniert.


    apt update und full-upgrade habe ich als User "pi" mit sudo ausgeführt.

    Mit dem "übergeordneten Ordner" meinte ich den Ordner, wo das NAS eingebunden werden soll. In meinem Fall "/media/fritzbox".

    Code
    ls -al /media/fritzbox
    insgesamt 4
    drwxr-xr-x 2 pi   pi      0 Sep 24  2019 .
    drwxr-xr-x 5 root root 4096 Sep  3  2020 ..
    drwxr-xr-x 2 pi   pi      0 Aug  7 20:30 faxbox
    drwxr-xr-x 2 pi   pi      0 Aug  8 22:31 mediabox
    drwxr-xr-x 2 pi   pi      0 Jan  1  1970 voicebox


    In den Logfiles gibt es keinerlei Hinweis auf irgendwelche Fehler. df zeigt auch an, dass das Verzeichnis eingebunden ist.

    Und das hier kommt, wenn ich in ein Unterverzeichnis, bzw. ein Verzeichnis des NAS wechseln will:

    Code
    cd /media/fritzbox/mediabox
    -bash: cd: /media/fritzbox/mediabox: Datei oder Verzeichnis nicht gefunden

    Hallo zusammen,

    ich habe ein Problem mit einem eingebundenen Fritzbox NAS unter Raspberry Pi 4 mit aktuellstem Raspberry Pi OS.

    Ich habe den NAS-Ordner seit einiger Zeit, dank der guten Anleitung Netzwerkfreigabe mounten mit systemd Mount Unit von Hofei eingebunden. Das ganze lief nach anfänglichen Schwierigkeiten auf meiner Seite problemlos bei zwei verschiedenen Fritzbox Modellen (Cable 6490 und 7590). Beide laufen mit dem jeweils aktuellsten, stabilen FritzOS (7.27 bei der Cable und 7.28 bei 7590)

    Nach einem Update von Raspberry Pi OS (apt update und apt full-upgrade kann ich jedoch auf die Ordner innerhalb des eingebundenen NAS-Ordners nicht mehr zugreifen. Der mount selbst funktioniert weiterhin ohne Probleme (das heißt, der übergeordnete Ordner wird eingebunden und kann geöffnet werden). Beim Versuch in einen Unterordner zu wechseln (in meinem Fall z.B. "faxbox") kommt die Fehlermeldung zurück, dass die Datei oder das Verzeichnis nicht vorhanden sind.

    Ein Hinzufügen des sec Parameters in den Optionen des cifs mount Befehls, hat leider keine Änderung gebracht (ausprobiert habe ich alle Optionen außer die Kerberos Optionen).

    Ich habe sogar testweise probiert SMB v1 zu nutzen (vorher in der Fritzbox aktiviert), in diesem Fall kommt zwar auch keine Fehlermeldung, aber man kann gar nicht in den Überordner wechseln.

    Das ganze Verhalten macht mich etwas ratlos. Hat noch jemand eine Idee was ich probieren könnte?

    Um meine Frage selbst zu beantworten (bzw. für andere einen Hinweis zu geben): folgendes funktioniert aktuell bei mir (ich weiß aber nicht, ob damit dauerhaft das Problem behoben wird oder welche Änderung dafür gesorgt hat, dass es notwendig ist).

    Die Angabe des sec Parameters in den Options hat geholfen. In den Beispielen am Anfang wäre das also:


    Für den manuellen mount zum Testen:
    mount -t cifs -o credentials=/etc/smbcredentials,uid=1000,gid=1000,sec=ntlmv2 //192.168.178.1/fritzbox/ /media/fritz_nas

    In der systemd mount unit:
    Options=credentials=/etc/smbcredentials,uid=1000,gid=1000,sec=ntlmv2

    Hallo zusammen,

    ich habe nun leider erneut ein Problem mit dem Mount des Fritzbox NAS.

    Seit einem Update (apt update und apt full-upgrade) auf einem Raspberry Pi4 mit Raspberry Pi OS, gibt es folgendes Problem:

    Der mount selbst funktioniert ohne Probleme, es werden auch die üblichen Verzeichnisse angezeigt (faxbox, mediabox, voicebox), bei einem Versuch in eines der Verzeichnisse zu wechseln, kommt jedoch ein Fehler: "Datei oder Verzeichnis nicht gefunden".

    Zur Vollständigkeit: Fritzbox 7590 mit Fritz OS 7.28. Vor dem Update des Pi gab es keine Probleme.

    Eine Fehlermeldung in log Dateien konnte ich bisher auch nicht finden.

    Was kann ich tun, um den Fehler zu beheben?

    Hallo @ThomasL 

    Danke für die Rückmeldung.

    Etwas kurios: Nachdem ich das ganze ausprobieren wollte und den Raspberry Pi neu gestartet habe, hat es funktioniert (ohne manuellen Check).

    Entsprechend sind auch die Ausgaben in meinen Augen in Ordnung:



    Für mich sieht es so aus, als müsste das passen.

    Ich hoffe einfach mal, dass es soweit stabil läuft. Danke für die Rückmeldung!

    Ich bin Schritt für Schritt nach der Anleitung vorgegangen und habe mich versichert, dass der Inhalt (abgesehen von Zugangsdaten und mount-Pfad) identisch ist.


    Das heißt umgekehrt, in einem Netzwerk mit Fritz!Box 7590 (noch mit SMB v1) funktioniert es - in einem anderen Netzwerk mit einer Fritz!Box 6340 Cable funktioniert es nicht und es gibt die Fehlermeldung "systemd failed with result 'dependency'".


    Abgesehen davon, dass dieser Fehler direkt oder indirekt mit der serverctl.service Datei zusammenhängt, habe ich leider auch keine weiteren Informationen. Deshalb auch meine Frage (auch wenn ich selbst verstehe, dass man mit diesen Informationen nicht sonderlich viel anfangen kann).

    Ausgelagert aus: Netzwerkfreigabe mounten mit systemd Mount Unit




    Hi zusammen,

    ich melde mich jetzt auch nochmal mit einem kleinen Problem.


    Ich habe mit Hilfe des Tutorials das Setup (Mounten der Fritz NAS) bereits einmal erfolgreich vollendet (auf einem Raspberry Pi 3 B+, Raspbian Buster). Das funktioniert tadellos.

    Ich habe jetzt das gleiche auf einem Raspberry Pi 4 B (auch Raspbian Buster) in einem anderen Netzwerk (auch Fritz!Box) versucht nachzubauen.
    Das manuelle Mounten funktioniert, nur beim Aufruf von systemctl start media-fritz_nas.mount scheitert es mit einer Fehlermeldung in etwa "systemd failed with result 'dependency'". Eingestellt ist der Raspberry so, dass er beim Booten aufs Netzwerk warten soll.

    Entferne ich in der .mount Datei die folgenden zwei Zeilen:


    Code
    Requires=serverctl.service
    After=serverctl.service


    klappt das Mounten ohne Probleme. Auch der manuelle Aufruf von /usr/local/sbin/serverctl 192.168.178.1 liefert ein positives Ergebnis.

    Leider weiß ich nicht woran das Problem liegen könnte, das Netzwerk ist sicher verfügbar.

    Da es ohne die Prüfung durch die serverctl.service klappt: Wie notwendig ist diese Prüfung, ob das Netzwerk verfügbar ist?

    Das Problem ist aber, dass es bis jetzt keinen Taster gibt, bei dem ich messen könnte.


    Da der Funk-Erweiterungssender auch keine speziellen Vorgaben macht, bin ich davon ausgegangen, dass es keine allzu starren Vorgaben gibt.


    Wenn ich aber die Informationen kombiniere, sollte ein CNY17F-4 Optokoppler mit einem vorgesetzten 1 kΩ Widerstand für meinen Zweck funktionieren.

    Erst mal danke für die Rückmeldungen! Ich habe mir schon gedacht, dass ich zu einfach gedacht habe.


    Für mein Verständnis und unter der Voraussetzung, dass ich den Weg mit einem Optokoppler probiere:


    Kann ich diesen Optokoppler verwenden?
    https://www.conrad.de/de/p/iso…transistor-dc-183249.html


    Und anschließend:

    Anode über einen ca. 400 Ohm Wiederstand an den GPIO

    Das heißt GPIO Pin 1 (also 3V?) und Kathode an Ground? Und Pin 1 dann ansteuern mit "GPIO.HIGH" und "GPIO.LOW"?


    Kann ich außerdem den Optokoppler bei gleicher Schaltung gegen das PhotoMOS-Relais tauschen?


    Danke für eure Hilfe!

    Hallo zusammen,

    ich habe mal wieder eine Einsteiger-Frage. Ich hoffe, dass ich hier richtig bin. Einen passenden Forumsbeitrag habe ich leider nicht gefunden.


    Mein Ziel in Kürze:
    Ich möchte mit einem Raspberry Pi (Modell 3B+ und 4B vorhanden) einen Klingeltastendruck "simulieren" (also auslösen) um den "Honeywell Funk-Erweiterungssender für verdrahtete Klingelanlagen DCP917S" anzusteuern. Ein kompatibler Honeywell Gong ist bereits im Einsatz. Anders ausgedrückt: Der Raspberry Pi soll die Klingel auslösen.

    Meine Recherche hat mich bisher leider nicht sehr weit gebracht bzw. mich verunsichert. Vermutlich reichen meine Elektronikkenntnisse nicht aus (da diese praktisch nicht vorhanden sind..)

    Benötige ich zusätzliche Hardware (ein Relais) oder kann ich z. B. den Klingeltastendruck mit den GPIO Pins und entsprechendem Kabel direkt simulieren?

    Mein Gedanke war beispielsweise ein Kabel mit dem GPIO Pin 1 (3V3) und dem Funk-Erweiterungssender sowie ein Kabel mit dem GPIO Pin 7 (GPIO 4) und dem Funk-Erweiterungssender zu verbinden. Anschließend (am Besten mit Python) GPIO Pin 7 mit "GPIO.HIGH" und nach einer Sekunde mit "GPIO.LOW" den Tastendruck zu simulieren.

    Kann ich das Vorhaben so umsetzen oder wird das nicht so einfach funktionieren?

    Über Hilfe würde ich mich sehr freuen. Danke auf jeden Fall im Voraus.

    Vielen Dank für eure schnellen Rückmeldungen!

    RTFM Anmerkung hat geholfen: mit "_netdev" funktioniert es nun tatsächlich. Ich bin davon ausgegangen, dass die Einstellung "Auf Netzwerk warten" dann für alle Systemkomponenten greift..


    Sollte es aber nochmal Probleme geben, werde ich auch auf systemd Mount Unit umsteigen.


    Bitte verzeiht einem Anfänger :)