Kann nicht auf Ordner movie zugreifen

Moleman · 26. Januar 2020, 12:13

Hallo,

ich habe ein Problem mit meiner Duo2. Ich kann nicht mehr auf den Ordner movie zugreifen. Versuche ich es kommt einer unendlich Spinner. Das passiert, egal wie ich es versuche (Movielist, VTI Dateimanager, Webif, Filezilla...). Ich kann aber auf alle anderen Ordner von der HDD zugreifen (movie_trash, Backup-Ordner usw.).

Was kann ich da machen? Fragt bitte, wenn ihr noch Infos braucht.

Danke

Dibagger · 26. Januar 2020, 12:27

Ich würde mal die Platte testen lassen. Den Test findest du im Gerätemanager.

hajeku123 · 26. Januar 2020, 12:29

du meinst vom PC aus auf den Ordner movie zugreifen?
Wenn du in der Movielist den Ordner "movie" aufrufst erscheint der Spinner auch?

Moleman · 26. Januar 2020, 12:51

Die Platte habe ich getestet. Der Test bricht ab mit der Meldung, möglicherweise defekt, oderso. Aber es betrifft nur diesen einen Ordner auf der HDD.

Egal wie ich auf den Ordner zugreife, es kommt immer eine endlos Spinner.

Dibagger · 26. Januar 2020, 12:55

Ja, da ist also das Dateisystem korrupt. Interessant wäre jetzt noch der genaue Wortlaut der Fehlermeldung, um die Erfolgsaussichten einer Reparatur abzuschätzen.

PS: Der Backup-Ordner ist noch in Ordnung? Dann würde ich an deiner Stelle schon mal eine Kopie der letzten Dateinsicherung(en) auf ein externes Medium (Stick, Platte) wegsichern.

Moleman · 26. Januar 2020, 13:07

Meldung:

Fehler

Fehler bei der Prüfung der Partition. Die Partition oder das Dateisystem könnten beschädigt sein

Dibagger · 26. Januar 2020, 13:11

Mein PS gesehen? Das würde ich jetzt als erstes tun, wenn noch möglich. Danach eine Dateisystemüberprüfung via Telnet.

Moleman · 26. Januar 2020, 13:17

Backup Ordner? Auf der Platte sind meine Aufnahmen, EPG Datei. Image Backups sind auf einer Synology.

Wie geht die Überprüfung über Telnet?

Dibagger · 26. Januar 2020, 13:21

Du hattest in deinem ersten Posting einen "Backup-Ordner" auf der HDD erwähnt ... Gbt es den nun oder nicht?

Moleman · 26. Januar 2020, 14:06

Ja, die gibt es und ich kann darauf zugreifen. Nur auf den Ordner movie kann ich nicht zugreifen.

Dibagger · 26. Januar 2020, 15:50

Den Dateisystemcheck in Telnet startest du mit:

e2fsck -vfD /dev/sda1

Das gilt für die erste Partition der internen Platte.

Aber Achtung! Es ist schon vorgekommen, dass hinterher gar nichts mehr auf der Platte ist. Daher mein Hinweis, dass du vorher noch wichtige Sachen auslagern solltest, soweit du darauf Zugriff hast. Ich bin mir nicht sicher, ob du das ernstgenommen hast. Also alles auf eigene Gefahr! Ich wüsste sonst aber keine Alternative.

Der Check kann ziemlich lange dauern, über eine Stunde. Nicht vorher abbrechen, auch wenn sich scheinbar nichts tut!

Telnet – Vu+ WIKI

Ach ja: Vorher die Festplatte im Gerätemanager aushängen.

Moleman · 26. Januar 2020, 16:40

Ich danke euch. Ich werde es versuchen. Wichtige Sachen sind auf der Synology. Geht jetzt eigentlich nur um die Aufnahmen im movie Ordner, die hätte ich eigentlich gern noch behalten.

Error reading block 34111491 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error<y>?

Die erste Meldung. Ignorieren?

RickX · 26. Januar 2020, 16:58

Um mit dem Test erstmal voran zu kommen, musst Du die Meldung ignorieren.
Die hört sich aber schon nicht gut an... kann sein, dass da noch mehr fehlerhafte Blöcke kommen.

Moleman · 26. Januar 2020, 17:00

Jetzt fragt die Box aber:

Force rewrite<y>?

Dibagger · 26. Januar 2020, 17:00

Einfach Enter (=y) drücken, das ist der Default. Das ist am besten, wenn man es nicht besser weiß ...
Könnte noch mehr davon kommen.

Gilt für folgende Fragen ebenso.

Moleman · 26. Januar 2020, 17:14

Spoiler anzeigen

root@vuduo2:~# e2fsck -vfD /dev/sda1 e2fsck 1.42.9 (28-Dec-2013) Pass 1: Checking inodes, blocks, and sizes Error reading block 34111491 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error<y>? yes Force rewrite<y>? yes Error reading block 34111492 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error<y>? yes Force rewrite<y>? yes Error reading block 34111493 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error<y>? yes Force rewrite<y>? yes Error reading block 34111494 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error<y>? yes Force rewrite<y>? yes Error reading block 34111495 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error<y>? yes Force rewrite<y>? yes Error reading block 34111497 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error<y>? yes Force rewrite<y>? yes Pass 2: Checking directory structure Error reading block 23953418 (Attempt to read block from filesystem resulted in short read) while reading directory block. Ignore error<y>? yes Force rewrite<y>? yes Directory inode 77953, block #13, offset 0: directory corrupted Salvage<y>? yes Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Error reading block 26673152 (Attempt to read block from filesystem resulted in short read) while reading inode and block bitmaps. Ignore error<y>? yes Force rewrite<y>? yes Pass 4: Checking reference counts Unattached inode 77954 Connect to /lost+found<y>? yes Inode 77954 ref count is 2, should be 1. Fix<y>? yes Unattached inode 78007 Connect to /lost+found<y>? yes Inode 78007 ref count is 2, should be 1. Fix<y>? yes Unattached inode 78058 Connect to /lost+found<y>? yes Inode 78058 ref count is 2, should be 1. Fix<y>? yes Unattached inode 78071 Connect to /lost+found<y>? yes Inode 78071 ref count is 2, should be 1. Fix<y>? yes Unattached inode 243717 Connect to /lost+found<y>? yes Inode 243717 ref count is 2, should be 1. Fix<y>? yes Unattached inode 243774 Connect to /lost+found<y>? yes Inode 243774 ref count is 2, should be 1. Fix<y>? yes Unattached inode 243775 Connect to /lost+found<y>? yes Inode 243775 ref count is 2, should be 1. Fix<y>? yes Unattached inode 287197 Connect to /lost+found<y>? yes Inode 287197 ref count is 2, should be 1. Fix<y>? yes Unattached inode 287213 Connect to /lost+found<y>? yes Inode 287213 ref count is 2, should be 1. Fix<y>? yes Unattached inode 287962 Connect to /lost+found<y>? yes Inode 287962 ref count is 2, should be 1. Fix<y>? yes Unattached inode 295047 Connect to /lost+found<y>? yes Inode 295047 ref count is 2, should be 1. Fix<y>? yes Pass 5: Checking group summary information Block bitmap differences: +(26673152--26673167) +(26674563--26674567) +(26676905--26676911) +26678671 +(26681013--26681015) +(26682779--26682783) +(26684833--26684839) +26687175 +(26689229--26689231) +(26691283--26691287) +(26693337--26693343) +26695391 +(26697445--26697447) +(26699499--26699503) +(26701265--26701271) +(26705373--26705375) -(28409866--28409871) Fix<y>? yes Free blocks count wrong for group #814 (0, counted=32689). Fix<y>? yes Free blocks count wrong for group #867 (32672, counted=32678). Fix<y>? yes Free blocks count wrong (13931782, counted=13964477). Fix<y>? yes /dev/sda1: ***** FILE SYSTEM WAS MODIFIED ***** 758 inodes used (0.25%, out of 305280) 141 non-contiguous files (18.6%) 7 non-contiguous directories (0.9%) # of inodes with ind/dind/tind blocks: 266/137/29 64178328 blocks used (82.13%, out of 78142805) 0 bad blocks 46 large files 729 regular files 14 directories 0 character device files 0 block device files 0 fifos 0 links 6 symbolic links (6 fast symbolic links) 0 sockets ------------ 738 files

Danke. Ich kann wieder auf movie zugreifen.

GaborDenes · 26. Januar 2020, 17:28

Jetzt schnell alles Wichtige sichern, nach meiner Einschätzung läuft die HDD nicht mehr lange, zumindest nicht zuverlässig.

Dibagger · 26. Januar 2020, 17:43

Das Letztere würde ich so nicht unbedingt sagen. Meiner Meinung nach haben Dateisystemfehler keine technischen Ursachen, jedenfalls nicht direkt auf die Platte bezogen.

@Moleman

Aufnahmen sind vollzählig und vollständig? Irgendwas im Ordner lost+found vorhanden?

GaborDenes · 26. Januar 2020, 17:46

Moleman schrieb:

(Attempt to read block from filesystem resulted in short read)

das interpretiere ich als HW-Fehler, also defekten Block.
Und in meiner Berufslaufbahn war ein erster defekter Block meistens der Beginn vom Ableben. Davon abgesehen schadet ein Backup nie :thumbup:

Dibagger · 26. Januar 2020, 18:02

Beim Backup stimme ich dir unbedingt zu. Mit ablebenden Festplatten hatte ich über Jahrzehnte privat und beruflich sehr selten zu tun, weiß gar nicht, ob überhaupt jemals. Unberufen, toi, toi, toi.

Aber richtig - lieber vorsichtig sein, als später das Nachsehen haben.