Volume erweitern -> Vorgang fehlgeschlagen, weil im Dateisystem Fehler aufgetreten...

[Cosmo Kramer]

Volume erweitern -> Vorgang fehlgeschlagen, weil im Dateisystem Fehler aufgetreten...

Hallo Community,
ich habe leider mal wieder ein Problem und konnte selbst nach Stunden der Suche nichts finden was mir weiterhelfen würde
Ich arbeite seit Jahren fast ausschließlich mit Linux und auch die Synologys begleiten mich seit nunmehr mehr als 7 Jahren,
doch leider bin ich mit meinem Latein am Ende und weiß auch schon nicht mehr nach was ich noch suchen sollte

Erst mal kurz ein paar Infos zum Sytem, ich habe eine DS1812+ mit dem aktuellen DSM 6.0-7321, darin befinden sich insgesamt 8 Platten.
Davon waren bis vor ein paar tagen 8x Seagate 2TB Platten (ST2000DM001) drin, aufgeteilt in 2 Volumes ->
6x 2TB in RAID5 für Volume 1
2x 2TB in RAID1 für Volume 2

Aufgrund von 98% Auslastung auf Volume 1 wurde der Speicher auf die neuen Seagate NAS (ST3000VN000) hochgezogen.
Die Stückweise-Wiederherstellung mit allen Platten hat wunderbar geklappt, aber leider lässt sich der Speicher nicht erweitern.
Jedes mal wenn ich im "Speicher-Manager" auf das Volume1 gehe und unter "Verwalten"
den Punkt "Das Volume mit nicht zugewiesenem Festplattenspeicherplatz erweitern" auswähle,
kann ich den nächsten schritt zwar noch bestätigen, sobald ich aber "Übernehmen" anklicke, kommt die Meldung
"Vorgang fehlgeschlagen, weil im Dateisystem Fehler aufgetreten sind".

Ich habe bereits mehrfach neu gestartet, mehrmals die "RAID Bereinigung" ausgeführt und auch den SMART-Test in der langen, intensiven Version ausgeführt.
Alles ohne irgendwelche Fehlermeldungen und immer mit den Meldungen "Normal".

Als Pakete laufen im Moment ...
- Antivirus Essential
- Audio Station
- Cloud Station Server
- Directory Server
- DNS Server
- Docker
- Download Station
- Hyper Backup
- Hyper Backup Vault
- iPKGui
- Java7
- Mail Server
- Mail Station
- MariaDB
- Medienserver
- nano
- Note Station
- ownCloud
- Perl
- Photo Station
- PHP 5.6
- phpMyAdmin
- Proxy Server
- Speicher-Analysator
- Surveilance Station
- Text-Editor
- Time Backup
- TVheadend
- USB Serial Drivers
- Video Station
- VPN Server
- Web Station

Ich werde jetzt noch mal versuchen alle Pakete zu deaktivieren, glaube allerdings nicht das es mich weiterbringen wird.
Vielleicht habt Ihr ja noch eine Idee was ich probieren könnte, oder hattet schon mal das gleiche Problem ???
Was allerdings auf Grund der ~9TB Daten nicht möglich ist, ist die Daten wo anders auszulagern und das RAID komplett zu löschen und neu aufzusetzen.
Soviel Speicher habe ich nirgends zur Verfügung und ein neues NAS ist leider auch nicht drin.
Aber ich denke das wird 99% der Nutzer hier ebenfalls so gehen

Über Hilfe von Euch würde ich mich auf jeden Fall riesig freuen.
Schon mal besten Dank im Voraus für Eure Mühe und Tips.

Mit freundlichen Grüßen
Cosmo

 

[goetz]

Hallo,
lies Dir mal dieses ganz in Ruhe durch.

Gruß Götz

 

[Cosmo Kramer]

Vielen lieben Dank für den Tip,
aber hier ergeben sich leider schon wieder neue Probleme ...

Ich melde mich über "ssh admin@synoadresse" auf der syno an.
Wechsle dann mit "sudo -i" auf den root account.
Hier fahre ich die Syno Dienste herunter mit "syno_poweroff_task -d"
Enable wie befohlen mit "vgchange -ay" das Volume
suche dann mit "ls -d /dev/v*" nach dem Volumename und finde leider nichts
Alles was kommt sind ...
/dev/vcs
/dev/vcs1
/dev/vcsa
/dev/vcsa1
/dev/vga_arbiter

aber leider kein /dev/vg*

In der DSM sehe ich auch nur Volumes und keine Diskgruppen, kann diese auch nicht anlegen.
Liegt darin irgendwo der Fehler ?
oder ist das bei DSM6 jetzt anders gelöst als mit den /dev/vg*

Mit verzweifeltem Gruß,
Cosmo

 

[goetz]

Hallo,
schau mal unter /dev/mapper , da sollte es ein vgXXXX geben.

Gruß Götz

 

[Cosmo Kramer]

Hallo Götz,

vielen Dank für deine weitere Hilfe.
Unter /dev/mapper/ gibt es tatsächlich dann die passenden links

control
vol1-origin
vol2-origin

in meinem Falle dann wohl die vol1-origin.

Aber wenn ich mit "fsck.ext4 -pvf -C0 /dev/mapper/vol1-origin" loslege, motzt er "/dev/mapper/vol1-origin is mounted. e2fsck: Cannot continue, aborting."

Wenn ich dann allerdings einen "umount /volume1" oder sogar "umount -f /volume1" machen möchte, will er das auch wieder nicht tun.
"umount: /volume1: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).)"

Mache ich dann ein "lsof /volume1" bekomme ich dieses zurück ...

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 19157 admin cwd DIR 253,1 4096 283893761 /volume1/homes/admin
sudo 19161 root cwd DIR 253,1 4096 283893761 /volume1/homes/admin
lsof 19182 root txt REG 253,1 121368 530038851 /volume1/@optware/sbin/lsof
lsof 19183 root txt REG 253,1 121368 530038851 /volume1/@optware/sbin/lsof


letzte Hoffnung war ein "fuser -mk /volume1", aber damit beendet er dann auch meine SSH-Session.
Ich habe ja langsam echt das neue DSM6 mit der neuen SSH-Anmeldung bei der root ja nur noch über admin mit sudo -i funktioniert im verdacht.
Gibt es dafür irgendeinen workarround ?



Ich könnte heulen, hab absolut keine Ahnung wie ich das umgehen soll und das Volume endlich aushängen kann, nachdem er ja nicht mal beim -force das Volume freigibt


Hast Du oder sonst jemand hier noch einen hilfreichen Tip ?
Google war bisher auch nicht wirklich hilfreich dazu ...

Besten Dank im Voraus,
Cosmo

 

[Cosmo Kramer]

Ich war auch nicht untätig und deshalb ein kleines Update ...

was mir aufgefallen ist, ist das 2 mal sshd läuft.
Anscheinend 1x vermutlich vom IPKG und 1x vermutlich vom DSM.
Die SSH Verbindung scheint allerdings die vom IPKG zu nehmen und blockiert mir damit natürlich das Volume1 (IPKG/@optware).
Das erklärt auch warum ich mit "fuser -mk /volume1" rausfliege bzw. ich auch schon beim "syno_poweroff_task -d" rausfliege und mich neu verbinden muss.
Hatte mir da erst noch nichts dabei gedacht, aber so langsam glaube ich zu wissen wo der Hase läuft ...

ich versuche mal die Ports umzubiegen um auf den originalen SSHD zu kommen.
Ist das generell ein Problem wenn 2 SSH-Daemons laufen, das ist doch bestimmt nicht sonderlich hilfreich bzw sicher, oder ?

Cosmo

 

[goetz]

Hallo,
als erstes hänge erst mal optware aus. Wenn optware nicht mehr gemountet ist dann nach syno_poweroff_task -d per mount schauen ob volume1 noch eingehangen ist. Ich hab es gerade mal durchgespielt, admin login und sudo -i stören nicht.

Gruß Götz

 

[Cosmo Kramer]

Super, vielen Dank für deine weitere Hilfe und deine Tests.

Aber wie hänge ich optware aus ?
mit "umount /opt" sagt er nur "not mounted"
Muss ich hierbei einen anderen Ort zum aushängen angeben ?

Gruß Cosmo

 

[goetz]

Hallo,
ist /opt ein Symlink? Wenn ja lösche ihn, neu anlegen kann man später wieder. Wenn /opt ein Symlink ist könnte es reichen die Reihenfolge in $PATH zu ändern damit alle Verweise auf opt nicht am Anfang sondern am Ende von $PATH stehen.

Gruß Götz

 

[Cosmo Kramer]

Hallo Götz,
danke für dein Durchhaltevermögen ...

Ja /opt ist ein Symlink, hatte ihn zwischenzeitlich auch schon mehrfach gelöscht, interessanterweise ist er nach jedem reboot automatisch wieder da.
Wo genau der immer wieder gesetzt wird (eigentlich ging ich davon aus das er bei der Installation von IPKG von Hand gesetzt wird) entzieht sich im Moment noch meiner Kenntnis.
PATH habe ich in der /root/.profile und in der /etc/profile ganz nach hinten geschoben, funktioniert auch.
Ein echo $PATH spuckt mir die /opt/bin und /opt/sbin ganz am Schluss aus.

Leider bekomme ich das Volume1 immer noch nicht unmounted.
selbst nach dem syno_poweroff_task -d (das mich verwirrenderweise aber immer wieder direkt aus der ssh session wirft) spuckt mir mount das Volume1 als gemounted aus.
ein umount /volume1 schlägt selbst mit force immer wieder fehl.
Ist es vielleicht doch IPKG was mir da einen Strich durch die Rechnung macht ?

Danke mal wieder im Voraus für Deine Mühe,
Cosmo

 

[Cosmo Kramer]

Habe hier noch etwas gestöbert und probiert http://www.synology-forum.de/archive/index.html/t-16716.html

hänge da aber bei dem Punkt :
springm 13.12.2010, 11:02
fuser hatte ich mit dem Paket psmisc schon installiert. Leider führt fuser -mk /volume1
zu sofortigem Ausloggen, vermutlich weil der ssh-Dämon auch in /opt liegt
Den fsck-thread hab ich gefunden, aber im Moment hilft er mir noch nicht so richtig weiter...
Update: in der Systemsteuerung den "normalen" sshd aktiviert, jetzt läuft der fsck

Was genau meint er mit den "normalen" sshd aktiviert ...
Ist das vermutlich genau das was ich mir schon dachte mit dem sshd vom IPKG anstatt von der DSM.
Bloß wie aktiviert man den "normalen sshd" anstatt des anderen ???
Da blicke ich zu so später stunde leider garnicht mehr durch

Cosmo

 

[goetz]

Hallo,
wie hast Du ipkg installiert? Manuell oder als Paket EBI? Gibt es in /usr/local/etc/rc.d das Script optware.sh mit folgender Zeile
[ ! -h /opt -a ! -d /opt ] && ln -s /volume1/@optware /opt
wenn ja dann kommentiere diese Zeile aus (wenn der symlink beim Start nicht da ist so wird er angelegt).

Gruß Götz

 

[Cosmo Kramer]

Das habe ich damals nach diesem Wiki http://www.synology-wiki.de/index.php/IPKG installiert.
Und ja, das Script existiert und hat natürlich die Überprüfung drin.
Habe es jetzt auskommentiert und der /opt bleibt dann natürlich auch weg, aber auch dann funktioniert das alles leider noch nicht.
Die Platte bleibt gnadenlos gemountet, weder syno_poweroff_task noch umount kann daran was ändern.
Ich versteh die Welt nicht mehr, keine Ahnung was diese Blockade verursacht noch wie ich auch nur ansatzweise dahinter kommen könnte.
Da ich zwischenzeitlich immer mehr typos rein haue, werde ich mich jetzt erst mal in die 2x2m begeben und morgen noch mal das Ganze von vorne angehen.
Vielleicht sehe ich im Moment den Wald vor lauter Bäumen nicht mehr.

mount gibt mir jedenfalls immer wieder
/dev/mapper/vol1-origin on /volume1 type ext4 (rw,relatime,journal_checksum,synoacl,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
zurück
und fuser -m /volume1
/volume1: 19250c 19253c
etwas in diese Richtung

fuser -mk /volume1 schließt jedenfalls die Session und ich muss mich neu anmelden.
Genau das scheint aber das Problem zu sein, aber ich finde keine Lösung dafür

Aber wie Gesagt, da ich mehr die Back-Taste als Buchstaben benötige, wirds Zeit für die Heia.
Die Kiste wird auch morgen noch zickig sein

Für weiterführende Tips bin ich natürlich auch weiterhin dankbar,
Gruß Cosmo

 

[Cosmo Kramer]

Guten Morgen, oder besser gesagt Mittag alle miteinander ...

oder wie man so schön sagt "ssdd"

Ich war nicht untätig, hab zig Threads durchwühlt und sehe immer wieder nur das gleiche ...
Seit DSM >5.1 hat Synology da ganz schön dran rumgebogen und einiges geht nicht mehr so wie es mal ging.
Auch das Telnet und SSH bei einem syno_poweroff_task geschlossen werden ist seit dort anscheinend so
und behindert ungemein die Arbeit am System, da es einem eben anscheinend immer wieder das Laufwerk blockiert wenn man sich anmeldet.

Deswegen mal die Frage, gibt es bei Synology die Möglichkeit mit einem "shutdown -rF now" einen sofortigen Check zu veranlassen und würde er dadurch genau meine Fehler beheben ?
Ein "touch /forcefsck" als Dauerlösung anzulegen bin ich mir nicht unbedingt sicher, da ich nicht weiß ob ich dann noch aufs System komme oder erst den Durchlauf abwarten müsste, sofern das überhaupt funktionieren würde.

Auf jeden Fall scheint man irgendeine Art von "FSCK on Reboot" zu benötigen oder irgendwas "manuell" zu machen, aber leider lässt sich nie jemand genau zu den "manuellen" schritten aus.
Synology hat anscheinend zwar eine Lösung die deren Service verwendet, den sie aber nicht verraten.
Vermutlich ein undokumentiertes Kommando für syno_poweroff_task oder ähnliches.

Den Syno-Service allerdings auf meine Kiste zu lassen finde ich irgendwie aber auch recht unentspannt, oder habt ihr damit schon Erfahrungen ?

Cosmo

 

[goetz]

Hallo,
shutdown kennt den Parameter F nicht. Meine DS mit 6.0 kennt kein fuser, was gibt "which fuser" aus? Hast Du noch eigene scripts oder mount --bind am laufen? Was ist in /usr/local/etc/rc.d? Irgendetwas hast Du noch am laufen, syno_poweroff_task -d darf Dich nicht aus der ssh Session werfen.

Gruß Götz

 

[Cosmo Kramer]

Okay, das hatte ich mir schon beinahe gedacht das er das nicht kennt.
Ob noch scripte laufen ist eine gute Frage, nicht das ich wüsste, allerdings bin ich mir da nach fast 4 Jahren nicht mehr so ganz sicher
Hätte ich jetzt gerne noch alles getestet, aber irgendwas scheint heute Morgen vermutlich schiefgelaufen zu sein, oder die Station führt ihrerseits gerade irgendetwas aus, keine Ahnung.
Auf jeden Fall blinkt sie nachdem ich sie eingeschaltet habe nur noch blau ohne piepen ohne Telnet, ohne SSH, kein WebIF und auch kein Ping möglich, selbst der Synology Assistant findet sie im Moment nicht mehr...

Hab sie mal hart abgeschaltet und ohne platten fährt sie zumindest soweit hoch, das Status nach knapp einer Minute gelb blinkt, sie kurz piept und Blau dauerhaft leuchtet, Board also zumindest mal noch heile.
Mit Platten allerdings das gleiche Spiel wieder ...
Es ist echt zum Mäuse melken, was soll ich eurer/deiner Meinung nach jetzt tun, einfach mal 24 Stunden so blinkend stehen lassen ?
Oder mit nur der 1sten Platte drin starten und das Volume crashen (was ja der Syno-Service in solchen Fällen anscheinend gerne mal macht).
Ich krieg hier echt gerade zu viel, kann denn nicht einmal etwas einfach klappen

Ein langsam doch verzweifelt werdender Cosmo