syno_poweroff_task ?

[wired2051]

Ich hoffe, dass du jetzt nach einmal drüber Schlafen etwas lockerer bist!? ;-)

Sorry, ich wollte Dich nicht wirklich anpflaumen aber dieses Problem habe ich jetzt seit Mitte April - langsam bin ich deshalb humorlos. ...und wirklich sehr froh über jede Hilfe!

Also, nun habe ich fsck.ext3 -vf /dev/md3 gemacht. Es kamen einige Meldungen wie diese, die ich alle mit "y" beantwortet habe.

Problem in HTREE directory inode 78323765: block #2 has bad min hash
Problem in HTREE directory inode 78323765: block #4 has bad min hash
Invalid HTREE directory inode 78323765 (/rsnapshot/daily.2/volume1/RECHNER/home/USER/.local/share/Trash/files).  Clear HTree index<y>?

Das ist die Zusammenfassung:

1.41.3-1139: ***** FILE SYSTEM WAS MODIFIED *****

 1371342 inodes used (1.13%)
   17547 non-contiguous files (1.3%)
    1989 non-contiguous directories (0.1%)
         # of inodes with ind/dind/tind blocks: 109037/5358/13
270930229 blocks used (55.61%)
       0 bad blocks
      57 large files

  895309 regular files
  448637 directories
       0 character device files
       0 block device files
       0 fifos
 4347402 links
   27357 symbolic links (25531 fast symbolic links)
      30 sockets
--------
 5718735 files

Leider bringt mich das bei meinem Problem nicht wirklich weiter. Nach anfänglichen Erfolgen beim löschen scheiterte ich bei hourly.6 bis hourly.10 schon wieder:

DS209> rm -rf hourly.8/volume1/RECHNER/home/USER/.local/share/Trash/
rm: cannot remove `hourly.8/volume1/RECHNER/home/USER/.local/share/Trash/info': Directory not empty
DS209> rm -rf hourly.9/volume1/RECHNER/home/USER/.local/share/Trash/
rm: cannot remove `hourly.9/volume1/RECHNER/home/USER/.local/share/Trash/info': Directory not empty
rm: cannot remove `hourly.9/volume1/RECHNER/home/USER/.local/share/Trash/files': Directory not empty
DS209> rm -rf hourly.10/volume1/RECHNER/home/USER/.local/share/Trash/
rm: cannot remove `hourly.10/volume1/RECHNER/home/USER/.local/share/Trash/info': Directory not empty
rm: cannot remove `hourly.10/volume1/RECHNER/home/USER/.local/share/Trash/files': Directory not empty

daily, weekly und monthly habe ich dann nicht mehr probiert.

 

[sgreg]

Nur am Rande, könnte es sein das auf die Dateien noch zugegriffen wird. Dh. das irgendwelche Prozesse noch zugreifen. Was passiert denn wenn du direkt in die Verzeichnisse gehts und dort löschen willst? Dann müßte er doch Dateinamen ausspucken, die nicht zu löschen sind. Die wiederum würde ich mal durch ps -ef |grep Dateiname suchen, welcher Prozess da noch querhängt. Good Luck.
Einen schönen Sonntagabend.

 

[wired2051]

Es ist immer wieder die gleiche Datei und die sieht sehr komisch aus, das hatte ich schon früher mal, woanders, gepostet (wie gesagt, das Problem verfolgt mich seit fast einem Monat).

DS209> cd files/
DS209> ls -lai
ls: cannot access C:\nppdf32Log\debuglog.txt: No such file or directory
total 24
29671445 drwx------ 2 USER Backup 20480 May  4 19:50 .
30244883 drwx------ 4 USER Backup  4096 May  4 19:48 ..
       ? -????????? ? ?        ?          ?            ? C:\nppdf32Log\debuglog.txt

Sie wird Dank eines Adobe Reader browser plugin Bugs immer wieder erzeugt und jetzt von mir nicht mehr gesichert.

 

[goetz]

Hallo,
wenn Du das Problem schnell los werden willst kommst Du um eine Datensicherung von Volume2 nicht herum wenn fsck nicht den gewünschten Erfolg brachte. Daten sichern, Volume2 löschen, neu anlegen und Rücksicherung.

Gruß Götz

 

[jan_gagel]

Hab den Thread gerade mal gelesen. Ziemlich böse diese Sache. Irgendwie wurde die Datei wohl nicht ganz korrekt im Dateisystem angelegt, denn Linux weiß ja überhaupt nix über die Datei. Keine Größe, keine Rechte, kein Datum, schon kurios. Wie reagiert denn das System, wenn du mit chmod oder chown die Rechte ändern möchtest? Bei kryptischen Dateinamen verwende ich gerne auch den mc zum Löschen, vielleicht klappts damit?
Oder was ganz anderes, die Festplatte ist aber noch in Ordnung? Nicht daß es hier verdeckte Hardware-Fehler, die das Dateisystem korrumpieren lassen? Wenn du beim Löschen wieder hängst, gibt ein neuer fsck-Lauf dann neue Fehler raus? Ansonsten hilft wohl nur noch die Variante, die goetz da beschrieben hat.

 

[wired2051]

Volume2 löschen, neu anlegen

Wie?

syno_poweroff_task
umount /volume1

Und dann? Ich nehme mal an, die sonstigen Konfigurationen (cron, rsnapsahort) liegen wo anders und bleiben erhalten? Ich muss an denen ja wohl danach auch nichts ändern, wenn die Platte wieder volume2 heisst, richtig?

 

[goetz]

Hallo,
im Speichermanager kannst Du das Volume2 löschen. Wenn Du nicht explizit Pakete auf Volume2 installiert hast bleiben alle Einstellungen und Pakete erhalten. Die definierten gemeinsamen Ordner und die vergebenen Rechte auf Volume2 sind dann aber weg.

Gruß Götz

 

[wired2051]

Danke für Deine Hilfe.

Meinst Du Speicher-Manager > Volumen entfernen? Wird dann auch die Platte neu formatiert? Wieder eingebunden?

Da ich so etwas nicht öfters mache, habe ich keine Ahnung. Übrigens, ich habe nicht den aktuellsten DSM, sondern DSM 3.0-1354.

 

[goetz]

Hallo,
genau so sollte es gehen. Die Partition sollte neu formatiert werden wenn ein neues Volume angelegt wird.

Gruß Götz

 

[wired2051]

Nun habe ich meinen Mut zusammengenommen (und die nötige Zeit eingeplant) mich dem Thema zu widmen.

Ich habe im Speicher-Manager Volumen entfernen gewählt und nach kurzer Zeit, inkl. Neustart des Webservers, kam diese "versuchen Sie eine Sicherung Ihrer Date, bevor Sie die das Volumen entfernen"-Fehlermeldung.

Besonders irritiert mich der Satz "Wenn Sie die Festplatte entfernen, achten Sie bitte darauf, dass mindestens eine Systemplatte [Datenträger 1, Datenträger 2] behalten werden muss, damit das System normal funktioniert."

Das ist jetzt über 2h her. Heisst das nun nur, ich muss Volume 2 Erstellen?

Sorry, aber ich habe grosse Angst etwas durch unüberlegtes Handeln falsch zu machen.

---edit---

Im Web-Interface wird mir diese Systemnachricht des Speicher-Managers angezeigt: "Volume 2 konnte nicht entfernt werden." Eine eMail bekam ich deshalb nicht.

 

[wired2051]

Hat sich erledigt. Offenbar war die Platte nicht richtig entfernt worden, nun läuft das Erstellen. Momentan bin ich bei ca. 25% der Festplattenprüfung.

Vielen Dank für die Hilfe!.

 

[wired2051]

Es hat doch nicht funktioniert.

Alles sah gut aus und ich habe einen gemeinsamen Ordner "Ablage" erstellt. Dann wollte ich homes von Volume1 auf Volume2 verschieben, dabei kam eine Fehlermeldung.

Nun kann ich über den Datei-Broweser keine gemeinsamen Ordner mehr sehen und bei Bedienfeld > Gemeinsame Ordner kommt nur unten links die rote Meldung "Vorgang fehlgeschlagen". Ich kann über den Speicher-Manager Volume2 weder Entfernen noch Erstellen.

In Speicher-Manager > HDD-Verwaltung ist bei beiden Datenträgern der Status Normal.

Ansonsten scheint die DS209 auch zu funktionieren: Die Photo-Station erreichbar, Dolphin kann ich alle gemeinsamen Ordner (die von Volume1 und Ablage von Volumen2) zugreifen (smb) und über Telnet komme ich auch auf die DS:

DS209> cd /volume2
DS209> ls -l
total 32
drwxrwxrwx 2 root root 4096 Jun 10 10:32 @tmp
drwxrwxrwx 2 root root 4096 Jun 10 10:28 Ablage
-rw------- 1 root root 7168 Jun 10 10:40 aquota.group
-rw------- 1 root root 8192 Jun 10 10:40 aquota.user
drwxrwxrwx 9 root root 4096 Jan  5 14:48 homes
drwx------ 3 root root 4096 Jun 10 10:30 rsnapshot

Ich nehme an, dass ein conr-Job während der Erstellung das Verzeichnis rsnapshot erstellt hat. Eben habe ich entdeckt, dass ich /etc/crontab zwar geändert habe aber vergass cron neu zu starten. Die rsnapshot-Sicherung wird offenbar durchgeführt, allerdings sind (via Telnet) die Umlaute durch ?? ersetzt und ich weiss nicht, ob das früher auch so war - aber das ist vermutlich ein anderes Thema.

Ein Neustart der DS209 hat nichts geändert.

Ich brauche Hilfe!