Announcement: there is an English version of this forum on Hi Ich habe versucht, die Daten einer Festplatte wieder herzustellen. Als Speicherort des Recovery Tools habe ich mein Synology NAS gewählt. Viele der wieder hergestellten Dateien sind defekt, darum hab ich sie später wieder gelöscht. Als ich nun den Trashcan des Laufwerks auf dem NAS leeren wollte, blieb ein Ordner über. Ich loggte mich über SSH ins NAS ein und sehe nun, dass in dem Ordner im Trashcan eine handvoll Dateien liegen, die ich aber nicht löschen kann. Beim Versuch, sie zu löschen, bekomme ich bei jeder Datei eine Fehlermeldung in der Form: rm: cannot remove 'zzz/xyz.jpg': Input/output error auch mit -f kann ich die Dateien nicht löschen. Hat jemand einen Tipp?
Klingt nach einem Fehler im Dateisystem. Mal fsck probieren.
Man könnte es unter Windows mit dem "Unlocker" versuchen. https://www.computerbild.de/download/Unlocker-6399684.html
Gerald K. schrieb: > Man könnte es unter Windows mit dem "Unlocker" versuchen. Ich kann mich auch irren, aber das sieht für mich nicht nach Windows aus: Freddy schrieb: > rm: cannot remove 'zzz/xyz.jpg': Input/output error > > auch mit -f kann ich die Dateien nicht löschen.
Moin, - die Antwort wir Dir nicht gefallen: Vermutlich hat die Platte einen Fehler. z.B.: https://unix.stackexchange.com/questions/39905/input-output-error-when-accessing-a-directory gucke mal dmesg an (sollte die HW-Fehler anzeigen). -> Es ist jetzt an der Zeit ueber die Wirksamkeit Deiner Backup-Strategie nachzudenken. Gruesse Th.
Frank H. schrieb: > Gerald K. schrieb: >> Man könnte es unter Windows mit dem "Unlocker" versuchen. > > Ich kann mich auch irren, aber das sieht für mich nicht nach Windows > aus: > Freddy schrieb: >> rm: cannot remove 'zzz/xyz.jpg': Input/output error >> >> auch mit -f kann ich die Dateien nicht löschen. Schon richtig, aber man könnte die Festplatte, sofern die Festplattenformatierung passt in einen PC als Zweitplatte einbauen und dann mittel "Unlocker" die Dateien und das Verzeichnis löschen.
Gerald K. schrieb: > Frank H. schrieb: >> Gerald K. schrieb: >>> Man könnte es unter Windows mit dem "Unlocker" versuchen. >> >> Ich kann mich auch irren, aber das sieht für mich nicht nach Windows >> aus: >> Freddy schrieb: >>> rm: cannot remove 'zzz/xyz.jpg': Input/output error >>> >>> auch mit -f kann ich die Dateien nicht löschen. > > Schon richtig, aber man könnte die Festplatte, sofern die > Festplattenformatierung passt in einen PC als Zweitplatte einbauen und > dann mittel "Unlocker" die Dateien und das Verzeichnis löschen. Seit wann kann Windows mit Linux-Filesystemen umgehen? Und warum sollte man ein Windows-Tool für Windows-Probleme nutzen für ein Problem was Unix-Filesysteme nicht haben?
Windows Hater schrieb: > Seit wann kann Windows mit Linux-Filesystemen umgehen? Ich verwende "Paragon Linux File Systems". Damit kann ich z.B. auch SD Karten für Raspberry Pi schreiben und lesen.
Thomas W. schrieb: > -> Es ist jetzt an der Zeit ueber die Wirksamkeit Deiner > Backup-Strategie nachzudenken. die Platten im NAS laufen im Raid5, werden beim ersten SMART Hickup oder spätestens nach 3 Jahren getauscht. Ich denke, dass das OS "denkt" der Fehler in den paar Dateien deutet auf das Filesystem hin; dabei wurden sie eben mit diesem Fehler von der erwähnten defekten -USB- Festplatte wiederhergestellt
Nun ja, dmesg mal angucken und dann weiter entscheiden. Wenn keine Fehlermeldungen da sind: fsck ist eventuell Dein Freund wenn Du die Platte/Partition aushaengen kannst (auch eingehaengt sollte ein fsck "vernuenftige" Ergebnisse geben). Gruesse Th. P.S.: die Zahlen der Klammern korrigiert
Thomas W. schrieb: > Nun ja, dmesg mal angucken und dann weiter entscheiden. Wenn keine > Fehlermeldungen da sind: fsck ist eventuell Dein Freund wenn Du die > Platte/Partition aushaengen kannst (auch eingehaengt sollte ein fsck > "vernuenftige" Ergebnisse geben). Es kann auch sein das die FS-Strukturen beschädigt sind und deswegen Blocknummern drinstehen die "außerhalb" der Platte liegen. Wenn die Blocknummern der IO-Errors verdächtig groß sind könnte das der Fall sein. fsck (nur checken, nicht reparieren) ist erst mal nicht verkehrt. Wenn du keine Erfahrung mit solchen Sachen hast, solltest du auch erst mal ganz vorsichtig an die Sache ran gehen um nicht noch mehr kaputt zu machen.
Freddy schrieb: > Viele > der wieder hergestellten Dateien sind defekt, darum hab ich sie später > wieder gelöscht. Mit was hast Du versucht die Daten wieder herzustellen?
PC-Freak schrieb: > Mit was hast Du versucht die Daten wieder herzustellen? mit EaseUS Data Recovery
Freddy schrieb: > die Platten im NAS laufen im Raid5, Das hat mit Backup nix zu tun, wie man am tollen IO-Error sieht. > werden beim ersten SMART Hickup oder > spätestens nach 3 Jahren getauscht. Dann kann es schon zu spät sein ...
:
Bearbeitet durch User
Freddy schrieb: > PC-Freak schrieb: >> Mit was hast Du versucht die Daten wieder herzustellen? > > mit EaseUS Data Recovery Verabschiede dich schon mal von deinen Daten wenn du gleich mit solchen Automatik Programmen ran gehst, anstatt erst mal mit Bordmitteln und /dev/brain.
Freddy schrieb: > Viele > der wieder hergestellten Dateien sind defekt, darum hab ich sie später > wieder gelöscht. Wenn Du auf die Daten abgewiesen bist, kannst Du mir die HDD schicken. Ich würde versuchen diese (soweit es geht) wieder herzustellen. Klappt aber nur, wenn Du keine Mega-Recovery versucht hast, bzw die Daten NICHT auf diese HDD zurück zu schreiben versucht hast.
Freddy schrieb: > Ich denke, dass das OS "denkt" der Fehler in den paar Dateien deutet auf > das Filesystem hin; dabei wurden sie eben mit diesem Fehler von der > erwähnten defekten -USB- Festplatte wiederhergestellt Nein, einen I/O-Error kann man nicht kopieren. Die Ursache muss eine andere sein. LG, Sebastian
foobar schrieb: > Freddy spekuliert: >> [...] > > Was sagt denn nun dmesg? Warum befragst du nicht Gugel
Dolly Dollar schrieb: > Warum befragst du nicht Gugel Hat Gugel Zugriff auf Freddys Synology? Das wird ja immer toller ... LG, Sebastian
Schau mal in "dmesg" nach. Dort müsste es bei einem I/O-Error eigentlich auch einen Eintrag geben, mit mehr infos.
Probier mal echo > zzz/xyz.jpg Damit wird die Datei erstmal auf 0Bytes gesetzt. Danach dann rm zzz/xyz.jpg Evtl klappt das ja.
Für sowas in Windows war früher immer eine DOS-Diskette gut. Oder ein Live-Linux. Live-Windowse gab es ja auch mal, auch diese wären eine Option gewesen. Fehlerhafter Assemblercode war schwieriger, da war es hilfreich, eine Textdatei mit Hinweisen mit dazuzulegen. Meistens hatte ich so "schwierige" Sachen aber nur auf DOS-Disketten geschrieben. DOS stürzte auch nicht gleich ab, wie Windows, wenn man so eine fehlerhafte Datei von Festplatte oder von einer Diskette aufruft. Für problematische Festplatten gab es u.a. auch diese hilfreichen Norton-Tools.
rbx schrieb: > Für sowas in Windows war früher immer eine DOS-Diskette gut. > Für problematische Festplatten gab es u.a. auch diese hilfreichen > Norton-Tools. Kinder kommt rein, die Siebziger sind zu Besuch… ;-)
könnte das auch ein Sache mit den "Besitzverhältnissen" sein?
sprich, bist du denn berechtigt
>zzz/xyz.jpg
zu löschen?
Ich hab grad gesehen, ich kann auch einen weiteren Ordner nicht löschen. Diesmal aber nicht wegen input/output error. Hier der ssh Mitschnitt: Freddy@homeNet:/volume1/Data/#recycle$ ls c zzz Freddy@homeNet:/volume1/Data/#recycle$ rm c -r rm: cannot remove 'c/level7481.0.json.~2~': No such file or directory rm: cannot remove 'c': Directory not empty Freddy@homeNet:/volume1/Data/#recycle$ cd c Freddy@homeNet:/volume1/Data/#recycle/c$ ls ls: cannot access 'level7481.0.json.~2~': No such file or directory level7481.0.json.~2~ hat jemand einen Idee?
Norbert schrieb: > Kinder kommt rein, die Siebziger sind zu Besuch… ;-) Hast du das Live-Linux absichtlich unterschlagen in deinem Zitat?
Nachtrag:
1 | Freddy@homeNet:/volume1/Data/#recycle/c$ ls -l |
2 | ls: cannot access 'level7481.0.json.~2~': No such file or directory |
3 | total 0 |
4 | -????????? ? ? ? ? ? level7481.0.json.~2~ |
Freddy schrieb: > hat jemand einen Idee? Sieht nach Filesystem aus. Deshalb wurde dir schon paarmal fsck vorgeschlagen. Und genauso oft wurdest du schon nach dmesg gefragt.
Wenn dmesg nicht funktioniert (gibt's das?), kannst du mal sowas probieren und das Ausgabefile (strace-rm) posten:
1 | strace -f -o /tmp/strace-rm rm zzz/xyz.jpg |
Andererseits: warum willst du die überhaupt löschen, viel wichtiger wäre doch, alle anderen Daten vom NAS in Sicherheit zu bringen. Es ist doch total egal, ob du die defekte Platte mit oder ohne xyz.jpg entsorgst?
Norbert schrieb: > Kinder kommt rein, die Siebziger sind zu Besuch… ;-) ja, eine überschaubare Filesystem-Auswahl und IT-Genies, die sich sowas wie Turing-Test, oder Merkbegriffe wie KISS ausdachten.
Frank H. schrieb: > Freddy schrieb: >> hat jemand einen Idee? > > Sieht nach Filesystem aus. Deshalb wurde dir schon paarmal fsck > vorgeschlagen. Und genauso oft wurdest du schon nach dmesg gefragt. Der TO will sich nicht helfen lassen.
Emil schrieb: > Frank H. schrieb: >> Freddy schrieb: >>> hat jemand einen Idee? >> >> Sieht nach Filesystem aus. Deshalb wurde dir schon paarmal fsck >> vorgeschlagen. Und genauso oft wurdest du schon nach dmesg gefragt. > > Der TO will sich nicht helfen lassen. Tja...
Freddy schrieb: > Hat jemand einen Tipp? 1.Mach erst mal ein komplettes Backup bevor noch mehr kaputt ist! 2.Versuche nie das eigene System zur Reparatur zu benutzen. Es wird auf die eigene Platte schreiben, wodurch wertvolle Daten überschrieben werden könnten. 3.Hast Du als User überhaupt Rechte dort zu löschen?
Emil schrieb: > Der TO will sich nicht helfen lassen. Vermutlich hat er jetzt die falsche Festplatte formatiert.
Hatte ich auch mal, ich konnte die Dinger zwar nicht löschen, aber ersetzen. Dazu hab ich in nem anderen Ordner eine Datei erstellt mit exakt demselben Namen und dann in den Ordner kopiert. Die Nachfrage, Datei ersetzen mit Ja beantworten und diese Datei konnte gelöscht werden.
Uli S. schrieb: > Hatte ich auch mal, ich konnte die Dinger zwar nicht löschen, aber > ersetzen. > Dazu hab ich in nem anderen Ordner eine Datei erstellt mit exakt > demselben Namen und dann in den Ordner kopiert. Die Nachfrage, Datei > ersetzen mit Ja beantworten und diese Datei konnte gelöscht werden. Aber das macht doch alles ein fsck selbst. Warum sollte man in einer kaputten Datenstruktur noch manuell rumfummeln, evtl. macht gerade das noch mehr kaputt. Ja, man muss das Filesystem unmounten und dafür evtl. neu booten, aber das geht das alles fix im Gegensatz zum Einspielen einen Backups (oder dem Gestochere in Resten, falls man keins hat...).
Uli S. schrieb: > Hatte ich auch mal, ich konnte die Dinger zwar nicht löschen, aber > ersetzen. > Dazu hab ich in nem anderen Ordner eine Datei erstellt mit exakt > demselben Namen und dann in den Ordner kopiert. Die Nachfrage, Datei > ersetzen mit Ja beantworten und diese Datei konnte gelöscht werden. Meist lässt sich eine blockierte Datei auch nicht in einen anderen Ordner verschieben. Aber vielleicht lässt sie sich im abgesicherten Modus löschen.
Gerald K. schrieb: > Meist lässt sich eine blockierte Datei auch nicht in einen anderen > Ordner verschieben. Das ist ja ein logisch nachvollziehbares Verhalten. Verschieben ist ja ein Löschen am alten Platz PLUS kopieren an den neuen Platz.
Entweder hat er keine ausreichenden Rechte oder die Datei ist noch im Zugriff oder das Dateisystem kaputt? https://de.wikipedia.org/wiki/Fsck
oszi40 schrieb: > Entweder hat er keine ausreichenden Rechte > oder die Datei ist noch im Zugriff > oder das Dateisystem kaputt? https://de.wikipedia.org/wiki/Fsck Mal schauen, ob jetzt eine Reaktion von ihm kommt. So oft, wie ihm das schon gesagt wurde...
Freddy schrieb: > Thomas W. schrieb: >> -> Es ist jetzt an der Zeit ueber die Wirksamkeit Deiner >> Backup-Strategie nachzudenken. > > die Platten im NAS laufen im Raid5, werden beim ersten SMART Hickup oder > spätestens nach 3 Jahren getauscht. Wer auf das Stichwort Backup mit RAID anfängt hat nichts verstanden. Der Sinn eines RAID ist Verfügbarkeit. Heißt Downtime im Fehlerfall zu vermeiden. Das hat mit Backup nichts zu tun und es ersetzt auch kein Backup.
Frank H. schrieb: > Gerald K. schrieb: >> Meist lässt sich eine blockierte Datei auch nicht in einen anderen >> Ordner verschieben. > > Das ist ja ein logisch nachvollziehbares Verhalten. > Verschieben ist ja ein Löschen am alten Platz PLUS kopieren an den neuen > Platz. Nur wenn es über Dateisystemgrenzen hinweg geschieht oder die Implementation schlecht ist. Sonst ist es nur ein Umhängen im Verzeichnisbaum.
Naja, raid ist immerhin schonmal ein klein wenig besser, als gar keine Zweitkopie. Von meinen wichtigen Daten (ein paar GB), habe ich tägliche Backups, und behalte die Jahre auf, und das Backup System hat auch nochmal RAID. Aber für meine paar TB Film Sammlung, hoffe ich einfach, dass nie zu viele Platten in dessen RAID den geist aufgeben. Das werden sonst einfach zu viele Festplatten...
Rolf M. schrieb: > Nur wenn es über Dateisystemgrenzen hinweg geschieht oder die > Implementation schlecht ist. Sonst ist es nur ein Umhängen im > Verzeichnisbaum. Für das "Umhängen" werden doch sicherlich auch bestimmte Berechtigungen nötig sein. Und da gibt es doch nur rwx--- Wenn dieser Vorgang keine Berechtigung "x" hat, kann es auch möglich sein, dass das Umhängen nicht funktioniert. Oder wie ist das?
Dieter D. schrieb: > Wer auf das Stichwort Backup mit RAID anfängt hat nichts verstanden. Der > Sinn eines RAID ist Verfügbarkeit. Wenn man fälschlicher Weise eine Datei ändert oder womöglich löscht ist durch Raidsystem nicht geschützt, aber durch ein Backup sehr wohl.
sofern fsck keine Fehler findet: mach Dich root (nicht den rm mit sudo davor sondern erst root):
1 | sudo -s |
dann nochmal versuchen, wichtig: mit vollem Pfad:
1 | rm /pfad/zur/datei/filename.jpg |
bzw.bei einem Ordner:
1 | rm -R /pfad/zum/ordner |
Frank H. schrieb: > Rolf M. schrieb: >> Nur wenn es über Dateisystemgrenzen hinweg geschieht oder die >> Implementation schlecht ist. Sonst ist es nur ein Umhängen im >> Verzeichnisbaum. > > Für das "Umhängen" werden doch sicherlich auch bestimmte Berechtigungen > nötig sein. Natürlich. > Und da gibt es doch nur rwx--- Wenn dieser Vorgang keine > Berechtigung "x" hat, kann es auch möglich sein, dass das Umhängen nicht > funktioniert. Oder wie ist das? Die Berechtigung x ist für das Verzeichnis nötig, ja. Aber wenn man die Berechtigung nicht hat, kommt als Fehler "Permission denied" und nicht "Input/output error".
Es wurde bereits mehrfach erwähnt mit dmsg mal zu schauen, ob das Blockdevice einen i/o error meldet. Wenn das so ist, führen die Versuche mit rm (und fsck ohne readonly-Option) dazu, das mit jedem "Test" das Dateisystem potentiell weiter Schaden nimmt. Aufgrund der Lernresistenz des OT können die Daten nicht wirklich wichtig sein ...
Rolf M. schrieb: > Die Berechtigung x ist für das Verzeichnis nötig, ja. Aber wenn man die > Berechtigung nicht hat, kommt als Fehler "Permission denied" und nicht > "Input/output error". Stimmt. Das x ist für Directories. Aber für das Umhängen sind doch auch Berechtigungen nötig. Könnte mir vorstellen, dass es "w" ist. Kann mir nicht vorstellen, dass das Umhängen ohne jede Berechtigung möglich ist.(!?)
Eine Datei mit Berechtigung/mode 0o000 lässt sich natürlich völlig problemlos verschieben (wenn sie einem gehört). Hier mit inode Anzeige.
1 | ~/tmp$ l -i dir2 |
2 | insgesamt 0 |
3 | 796681 ---------- 1 norbert norbert 0 Aug 29 18:14 AAA |
4 | ~/tmp$ mv dir2/AAA dir1 |
5 | ~/tmp$ l -i dir1 |
6 | insgesamt 0 |
7 | 796681 ---------- 1 norbert norbert 0 Aug 29 18:14 AAA |
8 | ~/tmp$ |
Was das ›x‹ wirklich bedeutet kann man aber problemlos herausfinden: man chmod oder: LC_ALL=C man chmod Allerdings gibt es extended attributes, da ist das Ding dann wirklich geschützt (selbst gegen eigene Blödheit und auch ›root‹) Und noch weiter darüber sitzen die Herren Bell und LaPadula.
Freddy schrieb: > Hat jemand einen Tipp? Lässt sich die Daten denn vllt. umbenennen? Denn wenn nicht liegt es sicher am Dateinamen oder der Länge davon?
Der einzige richtige Schritt ist nun die Festplatte auf blockdevice-Level auf Funktion zu prüfen. Sie ist ziemlich sicher kaputt. Alle Doktoreien auf FS-Ebene bringen gar nichts.
Freddy schrieb: > auch mit -f kann ich die Dateien nicht löschen. Hat jemand einen Tipp? Alle Dateien auf andere Festplatte oder großen USB Stick kopieren und dann Quellfestplatte formatieren.
:
Bearbeitet durch User
Gerald K. schrieb: > Alle Dateien auf andere Festplatte oder großen USB Stick kopieren und > dann Quellfestplatte formatieren. Dieser Rat ist etwas zu pauschal, da bisherige Rechte und Dateidatum wahrscheinlich bei Deinem einfachem Kopieren verändert werden.
oszi40 schrieb: > Gerald K. schrieb: >> Alle Dateien auf andere Festplatte oder großen USB Stick kopieren und >> dann Quellfestplatte formatieren. > > Dieser Rat ist etwas zu pauschal, da bisherige Rechte und Dateidatum > wahrscheinlich bei Deinem einfachem Kopieren verändert werden. Platte clonen
oszi40 schrieb: > da bisherige Rechte und Dateidatum > wahrscheinlich bei Deinem einfachem Kopieren verändert werden. Muss man halt die entsprechende Option angeben. cp -av rsync -av
Ich gehe davon aus das NAS basiert auf linux. Dann ist einfach so dass du keine RECHTE hast das zu löschen. https://wiki.ubuntuusers.de/chmod/ Linux kann da ab und zu mal sinfolles liefern wenn man sich auskennt.
Marco K. schrieb: > Ich gehe davon aus das NAS basiert auf linux. Ich auch :-) Betreff: > kann Datei nicht löschen unter Linux
Frank H. schrieb: > Gerald K. schrieb: >> Meist lässt sich eine blockierte Datei auch nicht in einen anderen >> Ordner verschieben. > > Das ist ja ein logisch nachvollziehbares Verhalten. > Verschieben ist ja ein Löschen am alten Platz PLUS kopieren an den neuen > Platz. Das kommt darauf an, ob das Kopieren innerhalb desselben Dateisystems stattfindet oder über Dateisystemgrenzen hinweg. Solange die Datei nur innerhalb desselben Dateisystems "kopiert" wird, wird sie nur umbenannt.
Marco K. schrieb: > Ich gehe davon aus das NAS basiert auf linux. > Dann ist einfach so dass du keine RECHTE hast das zu löschen. > https://wiki.ubuntuusers.de/chmod/ > Linux kann da ab und zu mal sinfolles liefern wenn man sich auskennt. Richtig ist, dass Linux "ab und zu mal sinfolles liefern" kann, wenn man sich auskennt. Du kennst Dich aber anscheinend nicht so gut aus, wie Du denkst, denn wenn Du Dich auskennen würdest, hättest Du erkannt und verstanden, dass da ein I/O-Fehler gemeldet wird und kein "Permission denied", wie es bei einem Rechteproblem der Fall wäre. Dieser Hinweis wurde im Thread, den Du anscheinend auch nicht gelesen hast, mittlerweile schon mehrfach gegeben.
hi bin seit Sonntag wieder zu Hause, gestern hab ich mich wieder mal um das NAS gekümmert. dmesg bringt folgende Fehler:
1 | [122103.715422] BTRFS critical (device dm-1): leaf bad key order, block=16497110630400, root=260, slot=46 |
2 | [122103.726038] BTRFS critical (device dm-1): leaf bad key order, block=16497110630400, root=260, slot=46 |
3 | [122103.736504] BTRFS error (device dm-1): cannot fix 16497110630400, record in meta_err |
Im NAS sind 5 Platten die in Raid5 laufen. Ich hab alle Platten einen extended SMART Test unterzogen, keine davon brachte dabei eine Fehlermeldung. Wie sollte ich weiter vorgehen?
Gucke mal in "btrfs check" oder "btrfs check --repair" (google oder man-Pages). Die Platte muss aber ausgehaengt sein. gruesse Th.
"Warning: Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume.". Ruhe bewahren, Daten sichern, Ursachenforschung betreiben. Erst mal gucken zu welcher Datei der Block gehört.
Eine Datei ist per Samba (SMB) nicht erreichbar, wenn der Pfad zu lang ist. Dann muesste man per linux zugreifen.
Wer btrfs produktiv einsetzt hat nicht mehr alle Tassen im Schrank und dann noch auf einem RAID - my god. Lernen durch Schmerzen.
Freddy schrieb: > die in Raid5 laufen Das verschlimmert die Sache noch, wie bei der Weihnachtbaumbeleuchtung. Eine richtige Datensicherung wäre jetzt nützlich.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.