raspibackup verliert Zugriff auf Fritz.nas

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
  • Hallo Forum,

    hier erst mal Info zu meinem Pi und zum Linux:

    Hier nun mein Problem:


    mit dem Skript "raspibackup" habe ich seit ca 3 Jahren regelmäßige Sicherungen auf dem Fritz.nas Laufwerk durchgeführt. Seit dem 06.03.2023 hat die Sicherung ihren Geist aufgegeben. Da ich mir keine Info habe zuschicken lassen, habe ich es erst vor kurzem festgestellt. Seit einigen Tagen versuche ich das Problem zu beseitigen. Bisher ohne Erfolg. Folgende Fehler bekomme ich angezeigt:



    In der Fritz.box ist ein "user" angelegt auch mit den nötigen Rechten und der ist in den letzten Jahren nicht geändert worden.

    Meine Vermutung weist auf Rechteprobleme hin ... aber ... . Vielleicht ist ja ein Linux Profi im Forum unterwegs und hat einen Tip für mich. Ich würde mich sehr freuen.

    cu perry94

  • Moin hyle

    vielen Dank für deine Rückmeldung. Hier das Gewünschte:


    Mount mit Option noserverino hat keine Verbesserung gebracht.


    Der Aufruf nano tt.txt ergibt

    Code
    [ Fehler beim Schreiben der Sperrdatei ./.tt.txt.swp: Datei oder Verzeichnis nicht gefunden ]


    cu perry94

  • Wenn Du einen cifs (Windows) Mount mit sudo ausführst und keine uid= gid= Option setzt, wird der User root berechtigt, und nicht der User "user".


    Servus !

    RTFM = Read The Factory Manual, oder so

  • sudo mount -t cifs -o credentials=$HOME/.smbcredentials,vers=3.0,noserverino,dir_mode=0777,file_mode=0666 //192.168.178.1/FRITZ.NAS/Ordner/Ordner/Sicherung/sich-pi-16gb/ /media/fritznas

    Dann sollte vers= und die flie/dir_mode Optionen überflüssig sein. Die Version wird automatisch ausgehandelt. Also, wenn du keinen speziellen Grund für die Optionen hast, kannst du diese weglassen. Die von RTFM genannten uid= und gid= machen allerdings Sinn. :)


    Benutzt du tar oder dd als Backup Methode?

  • Hallo daxb

    Benutzt du tar oder dd als Backup Methode?

    Meine Sicherungsmethode ist "tar".


    Wenn Du einen cifs (Windows) Mount mit sudo ausführst und keine uid= gid= Option setzt, wird der User root berechtigt, und nicht der User "user".

    Habe ich durchgeführt und hat leider keine Änderung ergeben.

    Der veränderte "mount" hat nicht das gewünschte Ergebnis erzielt.

    Meine Fritz.Box ist eine 6591-Cabel, wobei "Unterstützung für SMBv1 aktivieren" aktiviert worden ist. Das war aber schon immer so. Vielleicht hilft dieser Hinweis.

    cu perr94

  • pi@raspberrypi4-iob:~ $ sudo mount -t cifs -o credentials=$HOME/.smbcredentials,uid=1000,gid=1000 //192.168.178.1/FRITZ.NAS/Ordner/Ordner/Sicherung/sich-pi-16gb/ /media/fritznas

    So und jetzt noch noserverino mit rein und dann könnte es passen!


    Btw. Zeig uns bitte immer ls -lisa statt nur ls -l! Wir wollen auch versteckte Dateien und die verwendeten Inodes sehen.

  • Hallo hyle

    So und jetzt noch noserverino mit rein und dann könnte es passen!


    leider keine Änderung sichbar:

    cu perry94

  • perry94 Du verstehst jetzt warum ich Dich auf dieses Forum verwiesen habe :)


    Fuer alle Mitleser: Der TE hatte erst sein Problem auf meiner Kontakt Webseite die nun wirklich nicht fuer raspiBackup Fragen genutzt werden sollte :no_sad: plaziert, dann im ioBroker Forum als ioBroker Bug wo keiner natuerlich einen ioBroker Bug sah. Sowohl auf meiner Webseite als auch dann im ioBroker Thread habe ich immer wieder auf dieses Forum verwiesen weil ich weiss dass der TE hier guten Support bekommt :) . Zum Thema Samba/CIFS bin ich ein Noob und bin Euch dankbar dass Ihr dem TE helft :thumbup:


    Ich kenne Samba nicht so genau aber kann es sein dass ein FW Upgrade in der Fritte das Problem verursacht? Irgendwo habe ich mal gelesen dass irgendeine Samba/CIFs Version nicht mehr standardmaessig unterstuetzt wird von den Fritten.


    hyle Sollte der Thread nicht ins Backupforum verschoben werden?

    :no_sad: Kein Backup - kein Mitleid :no_sad:
    :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)
  • Sollte der Thread nicht ins Backupforum verschoben werden?

    Jain! ;) Meiner Meinung nach geht es hier nur sekundär um Backups, primär ist das ein CIFS-Mountproblem auf einem Linuxsystem.


    Wenn perry94 auf die Datei tt.txt zugreifen und diese bearbeiten kann, dann würde ich von einem Schaden im Dateisystem des an der Fritte angeschlossenen Laufwerks ausgehen und somit wär es dann auch kein Mountproblem mehr, sondern ein defektes Laufwerk usw. oder was auch immer in dieser Richtung passieren kann.

  • Hallo hyle,

    Aber nano tt.txt funktioniert und Du kannst die Datei bearbeiten oder?

    nein ... ich kann die Datei nicht bearbeiten.


    Du verstehst jetzt warum ich Dich auf dieses Forum verwiesen habe :)

    ja ... du hattest Recht ... hier bin ich ( hoffe auf eine Lösung :) ) besser aufgehoben


    ... Schaden im Dateisystem des an der Fritte angeschlossenen Laufwerks ausgehen und somit wär es dann auch kein Mountproblem mehr, sondern ein defektes Laufwerk ...

    Das Laufwerk war eine 2 Tbyte SSD ... da funkte es auch nicht mehr ab (wie gesagt) dem 06.03.2023 (vorher ohne Probleme) ... urplötzlich ohne eine Änderung an der Fritte oder sonstwo. Das das Laufwerk evt einen Schaden hat ... habe ich auch bedacht ... und eine neue SSD 4 tbyte installiert und eingebunden. Allerdings ohne Erfolg.


    cu perry94

  • Alle Energiesparmaßnahmen der FRITZ!Box sollten ebenfalls deaktiviert werden, das kann manchmal zu langen Reaktionszeiten führen. Ergo: Datei kann nicht gefunden werden ;)

    Wenn's brennt 112 hilft weiter!

  • ... dass Sperrdateien versteckt werden. Versuch mal rm tt.txt.swp!


    ... Was passiert mit dem absoluten Pfad nano /media/fritznas/tt.txt?

    bei beiden Versuchen

    Code
    pi@raspberrypi4-iob:/media/fritznas $ nano /media/fritznas/tt.txt
    pi@raspberrypi4-iob:/media/fritznas $ rm tt.txt.swp
    rm: das Entfernen von 'tt.txt.swp' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
    pi@raspberrypi4-iob:/media/fritznas $

    Auch "nano" funkt nicht ...


    Alle Energiesparmaßnahmen der FRITZ!Box sollten ebenfalls deaktiviert werden, das kann manchmal zu langen Reaktionszeiten führen. Ergo: Datei kann nicht gefunden werden ;)

    das ist geschehen ... keine Energiesparmaßnahmen aktiviert oder ähnliches


    cu perry94

  • In den Logfiles

    a.) vom Pi

    b.) der FritzBox

    gibt es keinen Hinweis auf die Ursache ?


    Z.B. auf a.) und b.) in /var/log/syslog*



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Btw. da ist vermutlich ein Punkt (.) vor tt.txt.swp zu viel. Ist aber auch möglich, dass Sperrdateien versteckt werden. Versuch mal rm tt.txt.swp!


    Was passiert mit dem absoluten Pfad nano /media/fritznas/tt.txt?


    hyle

    Code
    nano tt.txt
    
     [ Fehler beim Schreiben der Sperrdatei ./.tt.txt.swp: Datei oder Verzeichnis nicht gefunden ]

    cu perry94


    Wenn es eine versteckete Datei ist dann den RM mit dem . vor dem Dateinamen, wie oben zu sehen ist.
    rm .tt.txt.swp

    EDIT :
    Und schau mal auf die Fritzbox ob der User mit dem du mountest auch ausreichende Rechte hat.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    Edited once, last by Der_Imperator ().

  • Hallo hyle

    Was sind die Ausgaben von findmnt?


    hallo Der_Imperator

    Wenn es eine versteckete Datei ist dann den RM mit dem . vor dem Dateinamen, wie oben zu sehen ist.
    rm .tt.txt.swp


    Ergebnis

    Code
    pi@raspberrypi4-iob:/media/nas $ rm .tt.txt.swp
    rm: das Entfernen von '.tt.txt.swp' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
    pi@raspberrypi4-iob:/media/nas $


    Und schau mal auf die Fritzbox ob der User mit dem du mountest auch ausreichende Rechte hat.



    hallo rftm

    In den Logfiles

    a.) vom Pi

    b.) der FritzBox

    gibt es keinen Hinweis auf die Ursache ?


    Z.B. auf a.) und b.) in /var/log/syslog*

    zu a)



    zu b)


    Was mir aufgefallen ist command failed: Network is down (-100) ... Aber keine Idee woher das kommen könnte ... Das LAN läuft sonst einwandfrei


    Vielen Dank für eure Bemühungen ... Ich hoffe die Info hilft evt weiter


    cu perry94