externe HDD: das Entfernen von 'DataFile0013.txt' ist nicht möglich: Eingabe-/Ausgabefehler

  • Liebe Foren Community,


    ich habe eine Frage bezüglich Ein-/Ausgabe Fehlern.


    Ich nutze Raspbian Buster

    ich wollte einen Ordner mit offensichtlich korrupten Daten löschen.

    Leider klappt dies nicht, da ich einen EIn-/Ausgabefehler erhalte:

    Code
    rm -rf Messdaten/
    rm: das Entfernen von 'Messdaten/Scanner_20200729-12-17_DataFile0013.txt' ist nicht möglich: Eingabe-/Ausgabefehler
    rm: das Entfernen von 'Messdaten/Scanner_20200729-12-28_DataFile0000.txt' ist nicht möglich: Eingabe-/Ausgabefehler
    rm: das Entfernen von 'Messdaten/Scanner_20200730-18-17_DataFile0000.txt' ist nicht möglich: Eingabe-/Ausgabefehler

    dmesg liefert hier keine Informationen, aber ein paar Hinweise zur Platte:


    Habt ihr eine Idee, wie ich das Verzeichnis löschen kann und zukünftig solche Ein und Ausgabefehler vermeiden kann?

    Meine Raspis:

    RPi 2 B Rev 1.1 mit Raspbian 10.7 (buster): pihole

    RPi 3 B Rev 1.2 mit Raspbian 10.1 (buster): Logging Machine

    RPi 3 B Rev 1.2 mit Raspbian 9.13 (stretch): RetroPie

    RPi 3 B+ Rev 1.3 mit Raspbian 10.1 (buster): Logging Machine 2

    RPi 4 B Rev. 1.1 (4GB): noch offen



  • Was ist das für ein Microsoft Filesystem auf /dev/sda1 ?

    Wie wird es gemountet ?

    Hast Du jemals ein fschk auf das Filesystem ausgeführt ? Ev. nachholen.

    Wer hat Schreibrechte auf das Verzeichnis und die Files ? Und wer Leserechte ?

    Ergibt < ls -ali /Pfad/zu/Messdaten > eine plausible Anzeige ?


    Servus !


    Ed: Ein Eingabefehler kann auch entstehen, wenn die HD aus dem Schlafmodus noch nicht ganz aufgewacht ist (und neu gemountet wurde)

    RTFM = Read The Factory Manual, oder so

    Edited once, last by RTFM ().

  • Es ist eine externe Platte,

    in der /etc/fstab habe ich folgendes zum mounten eingetragen:


    Code
    PARTUUID=5e05273b-37fc-410a-9372-4e62424a9428 /media/Datenplatte ntfs rw,defaults,auto,users 0

    Du meinst vermutlich nicht fschk, sondern fsck, aber hier erhalte ich nichts sinnvolles. Hilfe (-h) half auch nicht weiter.

    Code
    sudo fsck /dev/sda1
    fsck from util-linux 2.33.1

    Ich habe dann noch fsck.ext4 probiert:

    Die Ausgabe ist plausibel, aber die Dateien sind eben problematisch:

    Meine Raspis:

    RPi 2 B Rev 1.1 mit Raspbian 10.7 (buster): pihole

    RPi 3 B Rev 1.2 mit Raspbian 10.1 (buster): Logging Machine

    RPi 3 B Rev 1.2 mit Raspbian 9.13 (stretch): RetroPie

    RPi 3 B+ Rev 1.3 mit Raspbian 10.1 (buster): Logging Machine 2

    RPi 4 B Rev. 1.1 (4GB): noch offen



  • Linux raspberrypi 4.19.75-v7+

    An dem Kernel sehe ich, daß du Berryboot benutzt. Hast du die externe HDD schon beim booten dran ?

  • Linux raspberrypi 4.19.75-v7+

    An dem Kernel sehe ich, daß du Berryboot benutzt. Hast du die externe HDD schon beim booten dran ?

    ja, die Platte hängt "dauerhaft" dran.
    Ob ich Berryboot habe, weiß ich aber nicht.

    Meine Raspis:

    RPi 2 B Rev 1.1 mit Raspbian 10.7 (buster): pihole

    RPi 3 B Rev 1.2 mit Raspbian 10.1 (buster): Logging Machine

    RPi 3 B Rev 1.2 mit Raspbian 9.13 (stretch): RetroPie

    RPi 3 B+ Rev 1.3 mit Raspbian 10.1 (buster): Logging Machine 2

    RPi 4 B Rev. 1.1 (4GB): noch offen



  • Ja was denn für ein Pi ? Pi 3, Pi 2 oder gar Pi 4 ? Und der 4.19.75 ist vom September oder kam mit dem Oktober Update.

  • Dann mounte einmal mit dem "ntfs-3g" Treiber, wenn die HD ntfs formatiert ist.


    Die ganzen EXT2/3/4 Tools funktionieren bei NTFS natürlich nicht.


    Und weil Windows keine Unix-Rechte kennt, musst Du im Mountbefehl mitgeben, wer Schreibrechte erhalten soll (uid= ,gid= )



    Servus !

    RTFM = Read The Factory Manual, oder so

  • soweit ich weiß wird ntfs-3g automatisch verwendet.

    Schreiben und Lesen funktioniert ja auch normalerweise.

    Ich vermute, dass die Fehler daher kommen, dass der Pi während den Dateioperationen plötzlich keinen Strom mehr hatte.

    Meine Raspis:

    RPi 2 B Rev 1.1 mit Raspbian 10.7 (buster): pihole

    RPi 3 B Rev 1.2 mit Raspbian 10.1 (buster): Logging Machine

    RPi 3 B Rev 1.2 mit Raspbian 9.13 (stretch): RetroPie

    RPi 3 B+ Rev 1.3 mit Raspbian 10.1 (buster): Logging Machine 2

    RPi 4 B Rev. 1.1 (4GB): noch offen



  • Wenn das NTFS Filesystem stromlos und korrupt wurde, kann das, genauso wie EXT4, über das Journal wiederhergestellt werden. Nur halt mir dem dafür vorgesehenem NTFS Programm. Da ich kein Windows habe, brauche ich weder NTFS, noch CIFS oder SAMBA, sodass ich Dir aus den man-pages nicht vorlesen kann. Du müsstest aus den NTFS-Tools mit < apropos ntfs > das passende Programm selbst suchen.


    Das NTFS Filesystem wird auch nicht beim Booten automatisch überprüft und repariert, wenn in der /etc/fstab an sechster Stelle keine 2 eingetragen ist. Siehe < man fstab >



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Danke für eure Hilfen.

    RTFM: ich habe gelesen, dass das Eintragen einer 2 an 6. Stelle (Überprüfen / reparieren) für ntfs Dateisysteme nicht empfohlen wird.


    Ich habe das nun dadurch gelöst, dass ich die Platte ext4 formatiert habe.


    Wenn das wieder vorkommt; wie kann ich das bei der ext4 Partition über das Journal reparieren?

    Meine Raspis:

    RPi 2 B Rev 1.1 mit Raspbian 10.7 (buster): pihole

    RPi 3 B Rev 1.2 mit Raspbian 10.1 (buster): Logging Machine

    RPi 3 B Rev 1.2 mit Raspbian 9.13 (stretch): RetroPie

    RPi 3 B+ Rev 1.3 mit Raspbian 10.1 (buster): Logging Machine 2

    RPi 4 B Rev. 1.1 (4GB): noch offen