kann Datei nicht löschen unter Linux

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.

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?

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:
> 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 spekuliert:
> [...]

Was sagt denn nun dmesg?

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.

PC-Freak schrieb:
> abgewiesen

Sollte :angewiesen - heißen

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… ;-)

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.

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?

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...

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?

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

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.

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:
> da bisherige Rechte und Dateidatum
> wahrscheinlich bei Deinem einfachem Kopieren verändert werden.

Muss man halt die entsprechende Option angeben.

cp -av
rsync -av

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.

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.