Hat jemand Probleme mit Bookworm und SMB und raspiBackup?

  • Jetzt habe ich den dritten raspiBackup Nutzer der sich mit einem raspiBackup Hang meldet. Unter Buster ging noch alles ohne Probleme und unter Bookworm haengt raspiBackup :@

    Konkret wird immer ein tar Backup auf einem SMB mounted Backupspace vorgenommen. Ein rasiBackup Nutzer ist auf eine lokale Platte umgestiegen und ein anderer raspiBackup Nutzer bleibt bei Buster denn da funktioniert alles wie es soll.

    Dem Debuglog nach haengt sich raspiBackup beim ls auf das Backupverzeichnis auf. Meine Vermutung ist dass sich irgendwelche Defaults beim SMB Client in Bookworm geaendert haben. Ein raspiBackup Nutzer hat die genutzen mount Optionen bei Buster und Bookworm verglichen und keine Unterschiede festgestellt.

    Dummerweise kann ich das nicht bei mir nachstellen um es weiter zu untersuchen. Bei mir laeuft der tar Backup ohne Probleme auf meiner Syno durch :fluchen:

    :no_sad: ... Kein Backup - kein Mitleid ... :no_sad:
    Nutze lieber raspiBackup bevor Du in die Luft gehst wie ein HB Männchen 💥

    Edited once, last by framp: TypoTypo (April 2, 2024 at 11:56 PM).

  • Hat jemand Probleme mit Bookworm und SMB und raspiBackup?? Schau mal ob du hier fündig wirst!

  • Wegen dem Problem kann ich nicht helfen aber Deine Umlaute sind kaputt ....

    Aber schau mal hier, ob das vielleicht hilft:

    Samba permissions changed in latest release and Bookworm - Raspberry Pi Forums

    Wobei Samba ja eher in Richtung Windows geht ?!?!

    Wobei SMB ja in Samba eingesetzt wird aber eine Googlesuche ergab halt viele User, die Probleme seit Bookworm damit haben.

    ;) Gruß Outi :D
    Pis: 2x Pi B, 1x Pi B+, 1x Pi 2 B in Rente / 2x Pi 3 B (RaspberryMatic / Repetier Server) / 2x Pi Zero 1.2 / 2x Pi Zero 1.3 / 2x Pi Zero W 1.1 / 1x Pi Zero 2 (BW+CUPS/SANE) / 1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (Tests) / Pi 400 (BW) / 1x Pi 5 (BW) / 2x Pi Pico / 2x Pi Pico W
    HATs: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT / Pimoroni NVMe BASE
    Cams: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • Bei mir laeuft der tar Backup ohne Probleme auf meiner Syno durch

    Ich kann das auch nicht nachstellen.

    Ich habe soeben ein tar-Backup auf einem Windows-Share erstellt.

  • Sag den Leuten, die sollen es mal mit noserverino als zusätzliche mount-Option versuchen, falls noch nicht geschehen!

    Danke. Warum sagt Dir das Dein Bauchgefuehl? Die Doku zu dieser Option ist fuer mich irgendwie nicht sonderlich hilfreich.

    Das komische ist ja dass Daten erfolgreich kopiert werden per rsync dann aber ein simpler ls zum Haeng fuehrt. Komischerweise offensichtlich auch nur wenn vorher viele Daten transferiert wurden. Nach einem Reboot haengt sich ein ls nicht auf.

  • Warum sagt Dir das Dein Bauchgefuehl?

    Immer wenn ich Zugriffsprobleme, ob lesend oder schreibend mit SMB am RPi hatte, standen mir die Inodes im Weg. Jetzt, nachdem ich weiß, dass es sich u.a. um eine Fritte handelt, verstärkt sich mein Gefühl sogar noch. ^^

    Wenn schreiben geht stellt sich mir die Frage: Wie genau arbeitet rsync und wohin schreibt das temporär?

  • Sag den Leuten, die sollen es mal mit noserverino als zusätzliche mount-Option versuchen, falls noch nicht geschehen!

    Ich habe gerade mal ein backup auf meiner Fritte laufen lassen.

    Ohne "noserverino" keine Chance

    Mountbefehl und Ausgabe von "mount"

    Code
    sudo mount -t cifs -o uid=1000,gid=1000,username=xxxxxxx,password=xxxxxxxxxxx //192.168.178.1/fritzbox /backup2
    
    //192.168.178.1/fritzbox on /backup2 type cifs (rw,relatime,vers=3.1.1,cache=strict,username=xxxx,uid=1000,noforceuid,gid=1000,noforcegid,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,closetimeo=1)

    Mit "noserverino"

    Mountbefehl und Ausgabe von "mount"

    Code
    sudo mount -t cifs -o uid=1000,gid=1000,noserverino,username=xxxxxxx,password=xxxxxxxxxxxxx //192.168.178.1/fritzbox /backup2
    
    
    //192.168.178.1/fritzbox on /backup2 type cifs (rw,relatime,vers=3.1.1,cache=strict,username=xxx,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.178.1,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1)

    Jetzt nach 1 Std. (Auf dem windows Share war alles nach 20 Minuten erledigt)


    Die LED an der SSD zeigt keine Aktivität mehr

    Screenshot vom FritzNas

  • Nachtrag / Korrektur zu #8

    1. Ich hatte mir ein Eigentor geschossen. Der Moutbefehl (Pfad zur Fritte war falsch) Ich hatte 192.168.178.1/fritzbox eingegeben, (interner Speicher) Natürlich muss es heißen 192.168.178.1/fritzbox/Volume :dau1:
      Merkwürdig ist nur, dass da keine Fehlermeldung kommt bzgl. Speicherplatz.
    2. hyle hat Recht. Ohne die Option "noserverino" funktioniert es auf der Fritte nicht.
      Da wird das Backup sofort mit RC2 abgebrochen.
    3. Das hängende Backup (keine Aktivität der SSD) habe ich nach 1,5 Std abgebrochen und mit dem richtigen Mountbefehl neu gestartet.
    4. Das Backup lief ohne Fehler durch.

    Fazit:

    Auf einem Windows-Share funktioniert raspiBackup (tar) mit oder ohne "noserverino"
    Auf einer Fritte ausschliesslich mit "noserverino"

    Zu einer Qnap kann ich nichts sagen, da ich keine (mehr) habe.
    Auf einem reinen Linux-System nutze ich kein SMB, sondern NFS.

  • Vielen Dank Franjo G fuer Deine Tests. Somit bestaetigst Du hyle s Bauchgefuehl :) Ich finde es sowieso nicht sehr geschickt die Firtte dazu zu nehmen - aber es kommen da immer mal wieder Fragen bzgl raspiBackup hoch und somit wird die Fritte durchaus als Poormans NAS genutzt. Es gab sogar mal jemanden der hat die Onlinespeicherfunktionalitaet der Fritte dafuer genutzt. Da hat natuerlich der Backup noch etwas laenger gedauert ... aber es funktionierte.

    Allerdings haben die Leute keinen RC2 bekommen sondern raspiBackup hing beim ls auf das Backupverzeichnis um die Backups zu recyclen. Und das ist bloed denn die warten dann erst mehrere Stunden und nachdem sie den Backup abbrechen denken sie es ist ein raspiBackup Problem. Aber irgendwo liegt der Hase vermutlich irgendwo im CIFS/SMB bei Bookworm.

  • hing beim ls auf das Backupverzeichnis um die Backups zu recyclen.

    Beim Abbruch des ersten Backupversuchs habe ich auch eine Meldung erhalten, dass Backup nicht gelöscht werden konnte und manuell gelöscht werden müsse.

  • Waere jetzt interessant wo raspiBackup genau hing :conf:

    Zu Deiner Info: raspiBackup erstellt das Debuglog im /tmp Verzeichnis und moved es am Ende entweder in das Backupverzeichnis oder ins Homeverzeichnis wenn irgendwas schief ging. D.h. wenn man raspiBackup brutal mit kill beendet steht das Debuglog zur weiteren Analyse in /tmp. Ein Abbruch mit CTRL C moved das Debuglog aber ins Homeverzeichnis.

  • Waere jetzt interessant wo raspiBackup genau hing

    Ich habe das jetzt noch einmal nachgestellt.

    Mount in den internen Speicher der Fritte.
    Sobald der interne Speicher voll ist

    stoppt die Festplattenaktivität.
    Im Terminal wird keine Fehlermeldung ausgegeben.

    Code
    --- RBK0085I: Backuperstellung vom Typ tar gestartet. Bitte Geduld.
    --- RBK0112I: Partition nvme0n1p1 wurde gesichert.
    --- RBK0092I: Partition nvme0n1p2 (67.1GB) wird gesichert ...
    --- RBK0158I: tar Backup "/backup2/pi5-lite/pi5-lite-tar-backup-20240403-190154/nvme0n1p2.tar" wird erstellt.
    --- RBK0085I: Backuperstellung vom Typ tar gestartet. Bitte Geduld.

    Abbruch mit CTRL und C

    Code
    ^C??? RBK0163E: Scriptausführung mit CTRL C abgebrochen.
    --- RBK0033I: Bitte warten bis aufgeräumt wurde.
    --- RBK0007I: Services werden gestartet: 'systemctl start smbd && systemctl start nmbd && systemctl start mariadb && systemctl start cron && systemctl start apache2'.
    --- RBK0043I: Unvollständiges Backup in /backup2/pi5-lite/pi5-lite-tar-backup-20240403-190154 wird gelöscht. Das kann etwas dauern. Bitte Geduld.
    rm: cannot remove '/backup2/pi5-lite/pi5-lite-tar-backup-20240403-190154': Directory not empty
    ??? RBK0105E: Löschen des unvollständigen Backups in /backup2/pi5-lite/pi5-lite-tar-backup-20240403-190154 schlug fehl mit RC: 1. Das Verzeichnis muss manuell gelöscht werden.
    --- RBK0026I: Debug Logdatei wurde in /home/franjo64/raspiBackup.log gesichert.

    raspiBackup.log

  • Vielen Dank fuer das Log.

    Aus dem ist zu sehen dass tar irgendwie nicht mitbekommt dass der Backupspace voll ist und einfach haengt :fluchen:

    Beim Aufraeumen kann auch /dev/nvme0n1p2 nicht umounted werden da tar offensichtlich noch seine Finger drin hat.

    Code
    rmdir: failed to remove '/tmp/nvme0n1p2': Device or resource busy 

    Weiterhin kann im Backupverzeichnis nicht aufgeraeumt werden mit dem Befehl rm -rfd <backupdir>

    Code
    --- RBK0043I: Unvollständiges Backup in /backup2/@HOSTNAME@/@HOSTNAME@-tar-backup-20240403-190154 wird gelöscht. Das kann etwas dauern. Bitte Geduld.
    rm: cannot remove '/backup2/@HOSTNAME@/@HOSTNAME@-tar-backup-20240403-190154': Directory not empty
    ??? RBK0105E: Löschen des unvollständigen Backups in /backup2/@HOSTNAME@/@HOSTNAME@-tar-backup-20240403-190154 schlug fehl mit RC: 1. Das Verzeichnis muss manuell gelöscht werden.

    Das moven des Debuglogs ins Homeverzeichnis klappt ja. Eigentlich muesste noch das laufende tar gekilled werden damit die Fehler nicht auftreten. Das zu kodieren und zu testen ist groesserer Aufwand. Wichtig ist dass eine Meldung kommt dass das unvollstaendige Backupverzeichnis manuell geloescht werden muss.

    Es gibt schon laenger diesen Issue der das manuelle Aufraeumen nicht mehr notwendig macht. Ich habe ihn unabhaengig von dieser Erfahrung schon vor laengerer Zeit wieder aus dem Backlog rausgenommen und werde ihn somit irgendwann angehen :shy:

  • Hallo zusammen,

    ich bin derjenige der diese Probleme hat. Ich habe ein QNAP, das share hat noch genug Speicherplatz. Die Sicherung funktioniert unter Buster und Bullseye einfwandfrei (frisch installierte Systeme). Ich nutze die aktuelle RaspiBackup Version.

    Es ist ein SMB Share, welche über die fstab eingebunden wird. Die fstab ist 1 zu 1 von einem Bustersystem übernommen worden und funktionierte so seit Jahren. Der Eintrag in der fstab ist:

    //192.168.178.29/raspberry /share cifs defaults,nofail,username=xxxx,password=xxxx,x-systemd.automount,x-systemd.requires=network-online.target,rw,file_mode=0777,dir_mode=0777

    Mit einem

    "noserverino" (was ich vor x-systemd.automount gesetzt hatte) bootete der Pi nicht mehr.


    Wenn ich noch irgendwas dazu beitragen kann gerne. Framp hat auch die Logs von raspibackup zu Verfügung. Dort ist klar zu erkennen, das sich das Ganze bei beim ls befehl aufhängt.

    viele Grüße

    Jens

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!