Hallöli,
wenn ich mein QNAP eingerichtet habe, sieht der Desktop so aus:
Bildschirmfoto 2018-05-06 um 17.54.59.png
Wenn ich aber ohne Internetverbindung boote (Firewall-Sperre im Router), verkrüppelt der Desktop in diese Form:
Bildschirmfoto 2018-05-06 um 18.44.14.png
Ich muss erst wieder die Internetverbindung einrichten und Rebooten, damit es wieder "schön" aussieht.
Kennt ihr das? Kann man dem QNAP irgendwie beibringen, ohne Internet sauber hochzufahren?
VG
Holger
Also ich würde sagen, Du hast es falsch eingesteckt.
Dual-Channel heißt "zwei Kanäle" 
Also bitte einen 8GB in Kanal A (Slot 1) und den anderen 8GB in den zugehörigen Kanal B (Slot 3). Nur dann hast Du auf den beiden 8GBs auch Dual-Channel, d.h. dass sie gleichzeitig angesprochen werden. Bei den beiden anderen analog.
Aner warum ist der QNAP-Text da so falsch? Er sagt ja hü und hott gleichzeitig? Oder ist das eine Anzeige, die Dir anzeigt, wie Du es aktuell eingestellt hast, und Dich darauf hinweisen möchte, dass das so nicht optimal ist?
Das war der Grund weshalb ich direkt zu dem NAS noch eine USV geholt hab
Ich hab eine, nur hatte ich das NAS zur Datenrettung auf den "Labortisch" geholt. Die USV blieb im "Serverregal", weil zu aufwendig. Und dann kommt genau der Sturm! 
Ein Rebuild belastet die Platten extrem
Das habe ich mich die Tage auch gefragt: Durch das ständige Neuinstallieren und 2x Stromausfall wegen Sturms hat sich bestimmt 5-6x das RAID synchronisiert innerhalb der letzten 14 Tage.
Aber ist es nicht so, dass eine Serverplatte das abkönnen muss? Im Grunde geht es doch recht linear voran, bei dieser Art von Zugriff. Einmal von vorne bis hinten durchscannen - müsste doch halbwegs verdaulich sein, im Vergleich zu 24/7 Datenbankrödeln z.B.?
Vielleicht, weil dann die Systempartitionen wieder resynct waren?
Hm, stimmt, guter Ansatz. Obwohl ich mich zu erinnern glaube, dass ich mir vor dem Boot mit cat /proc/mdstat das Raid angesehen hatte, und nur die Datenpartition war noch nicht in sync. Das spräche ein wenig dagegen.
Hallo,
eigentlich wollte ich das Verhalten bei Stromausfall eher mal unter Laborbedingungen testen. Leider hat mich die Praxis 2x eingeholt. Aktuell hab ich das QNAP nicht an der USV hängen, und der Sturm tat sein übriges. 
Dabei ist mir etwas passiert, was sich kurioserweise durch mehrstündiges Warten von selbst behob. Vielleicht stößt ja einer von Euch auch darüber.
Also: Während ich gerade am Kopieren von Dateien vom externen Laufwerk auf das interne Dateisystem war, gingen die Lichter aus. Strom weg. Das nahm ich zum Anlass, hinterher mal das Dateisystem zu prüfen. In der Tat blieben Inkonsistenzen zurück, und zwar nicht nur in den Dateien, die gerade geöffnet waren (das wäre i.O.), sondern auch in den ext4-Metadaten. Gefühlt war nix dramatisches dabei. Lies sich alles auch durch den "Dateisystemcheck" reparieren. Darf aber bei einem Journaling-Filesystem nicht passieren, deshalb werde ich mal ein Ticket erstellen. Vielleicht klappen ja manche Syncs nicht richtig. Vom ext4 über LUKS, LVM2, DRBD und RAID ist es ja ein etwas längerer Weg bis zur Platte runter. Ob das nun etwas mit dem folgenden Verhalten zu tun hat, weiß ich nicht.
Interessant war nun, dass ich das System nach dem Stromausfall genau einmal hochfahren konnte, und dann aber nicht mehr. Beim Booten hing er sich weg. Es stand auf dem Display:
Kein Netzwerkzugriff, kein Reset über On/Off-Knopf möglich. Nur 5-Sekunden-On/Off-drücken-Reset ging. Also tot.
Ich habe noch 1-2 Reboots probiert mit dem gleichen Ergebnis. Frustiert ging ich weg von der Anlage ... und ließ sie, warum auch immer, einige Stunden laufen. Und danach probierte ich noch einen Reboot - und der klappte! Das war mir unerklärlich. Bis der zweite Stromausfall kam. Da ist das gleiche wieder passiert! Ich war wieder am kopieren, als es geschah. Einmal booten ging wieder, dabei Filesystem reparieren usw., dann Neustart - und hängt schon wieder! Nun lief es wie der Zufall so will erneut einige Stunden von alleine. Und auch danach klappte der Neustart wieder. Crazy 
Nun habe ich eine Theorie, die ich aber nicht prüfen möchte: Nach dem Stromausfall begann das RAID ein resync. Der dauert ja bekanntlich. Kann es sein, dass es nicht bootet, falls das RAID nicht in snyc ist? Und dass er im Hintergrund aber weitersyncht, und irgendwann fertig ist, und danach dann der Reboot klappt? Dagen spricht, dass ein resyc bei mir so 5-6 Stunden dauert bei maximaler Geschwindigkeit. Und ich will nicht recht glauben, dass ich beim zweiten Stromausfall so lange schon gewartet hatte. Aber ausschließen kann ich es nicht. (EDIT: Kaum hatte ich es geschrieben, fand ich raus, dass er mit dem Sync erst bei 25% ist. Also warum klappt der Reboot plötzlich doch? @Gummiente: Vielleicht weil ich das Display ausgeschaltet hatte und es nun an ist?)
Falls also jemand auf das gleiche Problem stößt: Nicht gleich aufgeben, d.h. nicht gleich alles neu aufsetzen. Manche Probleme erledigen sich durch Warten?
VG
Holger
Anhang: Dateisystemfehler - betroffen sind offenbar nur Metadaten der Files, die gerade kürzlich geschrieben wurden, sowie das QTS-Event-Log, was ja vermutlich ebenfalls schreibend geöffnet war. Insofern alles wie es bei einem Non-Journaling-Filesystem zu erwarten wäre. Nix tragisches. Das Journaling sollte aber ja dazu da sein, dass auch diese Metadaten konsistent bleiben. Und das hat nicht funktioniert. Kennt sich jemand aus, ob man da irgendwas einstellen kann, damit das Journal auch nach unten durchgetragen wird? In alten Linuxen war das doch glaube ich nicht alles auf Robustheit voreingestellt, sondern auf Performance. Ich dachte aber, das wäre Geschichte?
genauso hab ich das auch verstanden und dir deshalb auch zugesichert, deinen EIngangspost 1 zu 1 vorzutragen
Finde ich eine gute Idee. Falls es zu einer Befragung kommt, würde ich mich - genügend aktuelle Freizeit vorausgesetzt - auch beteiligen.
Normalerweise mache ich das nicht so gerne, denke es ist Aufgabe der Produktmanager auch auf anderen Wegen an die Anforderungen zu kommen. Jeder hat so sein Hobbies und Ehrenämter, und meines ist eigentlich nicht, NAS-Anforderungen zusammenzustellen. Aber wenn's hilft. Stufe 1 ist für mich, dass QNAP versteht, was hier gerade los ist. Nämlich dass die Datenrobustheit nicht gegeben war, bzw. vielleicht sogar aktuell nicht gegeben ist (ich mag diese Filesysteminkonsistenzen, die teilweise sogar ohne Grund auftreten, nicht; und damit meine ich nicht die QNAP-spezifischen Formatänderungen, sondern echte Fehlermeldungen).
Wenn QNAP an so einer Befragung erkennen kann, dass keiner von uns Usern Datenverlust haben möchte (ich vermute, das ist bei allen Prio 1), dann macht es total Sinn, darauf aufsetzend über die anderen Funktionen zu reden. Für mich an zweiter Stelle: Kompatibilität der Formate. Für andere vielleicht was anderes. Aber Prio 1, hat da jemand was anderes als Datenhaltungsrobustheit?
Backup der Daten !!!
Bitte bitte bitte schreibt das nicht immer ganz so pauschal, ohne darauf hinzuweisen, dass man ein bestehendes Backup dabei nicht unbedingt überschreiben soll. Also unbedingt ein anderes Medium nehmen. Ich war hier auch auf einen solchen Forenbeitrag gestoßen und habe dann dummerweise das Backup überschrieben und hatte danach einen Dateisystemfehler sowohl auf der internen als auch auf der externen Platte. Das muss Euch ja nciht auch passieren.
Das ext4 ist nicht modifiziert
Hallo Christian,
ext4 ist ein Linux-Dateisystem, d.h. Linux definiert das Feature-Set und damit die Interpretationsregeln von ext4.
Jeder kann Modifikationen von QNAP gegenüber dem Linux-Original auf Sourceforge einsehen. Oder einfach mal mit QNAP ein "ext4" erstellen, eine gewisse Menge Dateien darauf schreiben, und dann unter Linux einen Filesystem-Check machen. Bei mir hagelt es Fehlermeldungen, z.B. bezüglich der meiner Auffassung nach inkompatiblen Verzeichnisindizes (HTrees):
Gibt es vielleicht einen Schalter, mit dem ich die Kompatibilität einschalten kann? Das wäre vielleicht eine Lösung. Die Ticket-Nummer kennst Du ja, ich habe das aufgeteilt:
Viele Grüße!
Holger
Das ist ja deine Behauptung?
Nein.
Fangen wir an persönlich zu werden ? Ganz dünnes Eis.
Irgendwie triften wir ab von "Datenverlust" in die Richtung "warum verwendest Du auch mehr Funktionen gleichzeitig". Beide Themen gehören zu der Überschrift dieses Threads. Aber schon etwas getrennt, und nicht als Argumentationsbogen. QNAP bewirbt ja übrigens aktiv die ext4-Kompatibilität.
Ich darf nicht auf mich selbst verlinken, weil aber sonst keiner antwortet, tue ich es trotzdem. Schau mal hier rein, ob Dir das hilft. Ich finde Deine Darstellung zu unstrukturiert, um erkennen zu können, woran Du hängst. Vielleicht ist das ein Grund, warum sich nur wenige melden. Ich könnte mir vorstellen, dass Du in o.g. Anleitung da einsteigen musst, wo es darum geht, das lv1 zu aktivieren und dann zu entschlüsseln. Danach die Linux-spezifischen Korrekturen sind ja für Dich irrelevant, wenn Du auf dem NAS arbeitest.
Versuch einen Downgrade auf 4.1.4
Jetzt kommt hier langsam mal Butter bei die Fische. Also Ross und Reiter: Welches Build?
Empfehle vorher Sicherung der Daten
Ich rate auch dazu, sofern dabei nicht ein vorhandenes Backup überschrieben wird!
Außerdem war ich vermutlich (Rettungsaktion läuft noch) damit erfolgreich, das betroffene Volume vor der Rettung zu unmounten, dann mit e2fsck zu "reparieren", dann mit "mount" zu mounten (also nicht über GUI bzw. qcgi, damit die Dienste nicht loslaufen), um dann mit rsync oder cp die Daten auf ein USB-Medium zu übertragen. Das USB-Medium erlitt dabei aber den gleichen Fehler - deshalb meine obige Empfehlung, nicht ein bestehendes Backup herzunehmen. Den wiederum habe ich dann aber an einem Linux wieder "repariert" (e2fsck) und dann die Daten erneut mit Linux auf ein neues Medium kopiert. Da liegen sie nun und harren der Dinge, dass ich wieder ein funktionsfähiges NAS bekomme, um dann zurückgespielt zu werden ...
Ansonsten direkt beim QNAP-Support melden, damit die die nötigen Informationen zum Ausbessern der Bugs erhalten.
Hehe, das würde ja nur Sinn machen, wenn man vorhat nach Erscheinen des Fixes das Update einzuspielen. 
Jedenfalls bin ich schockiert, dass es nach ext4 nun auch den LVM2 erwischt hat - in dem Bezug, dass aus den proprietären Anpassungen nun auch Bugs zu resultieren scheinen. Ich hatte nach der Erkennis der Anpassungen des LVM2 die 0551 nun ohne LVM2 aufgesetzt - zur Sicherheit. Snapshots fände ich eine extrem super Sache. Nur halt nicht proprietär und closed source, bitte. (Und ich werde nicht müde zu erwähnen, dass LVM2 m.E. unter GPL fällt. Bitte, liebes QNAP, die Patches endlich und kontinuierlich auch als open source veröffentlichen ...)
Meine Nächste wird wieder eine Eigenbau.
Ich hege die ganze Zeit den Gedanken, einen solchen "Eigenbau" auf die QNAP-Hardware zu setzen. Denn die Hardware scheint ja ganz cool zu sein. Meinst Du nicht, das könnte eine Idee sein? Allerdings finde ich nur alte Anleitungen, z.B. bzgl. Debian auf älteren QNAP-NASsen. Frage in die Runde: Gibt's da auch aktuellere Erfahrungen, z.B. mit Intel-Boxen?
Evtl. ist es dann eine bessere Idee, die externen Platten mit normalem Linux zu formatieren statt mit dem NAS oder gleich NTFS einzusetzen.
Das ist ein wirklich guter Punkt! Wie schon dargestellt ließen sich bei mir mit Koppix 8.1 formatierte ext4-Medien nicht ohne Weiters in QTS einbinden. Hinzu kommt die Sorge, dass diese beim Schreibzugriff durch QTS mit proprietären Aspekten (z.B. HTree-Einträge) inkonsistent werden könnten.
Aber eventuell kann ja mal einer herausfinden, welche ext4-Features man beim Formatieren einer externen Platte setzen muss / nicht setzen darf, damit QTS und Linux die so formatierte Platte erkennen und wechselseitig fehlerfrei lesen und schreiben können?
Das wäre doch schonmal ein erheblicher Fortschritt in der Interoperabilität.
Letztenendes muss man sich auch fragen: Was macht Sumpfdotter da eigentlich? Was soll das überhaupt? Ist der Vorteil von QNAP denn nicht, dass man genau das nicht machen muss, was Sumpfdotter da gerade macht. Ich finde es hochinteressant, aber eigentlich kann es mir komplett egal sein, wie QNAP seine Systeme aufbaut.
Wenn er so tief in die Materie einsteigt, warum erstellt er sich nicht seine eigene NAS auf freien Softwareimplementierungen, warum kauft er ein abgeschlossenes System wie QNAP mit all den Restriktionen?
Oh, da stimme ich Dir vollkommen zu! Lass nochmal nachrechnen ... 250€ NAS + 2x200€ Serverplatten + 50€ USB3.0-Gehäuse + 200€ Backupplatte. Geld gegen Zeit. Ein tolles Modell. Müsste doch reichen, um ein Datenarchiv und Backupsystem für meinen Laptop aufzuziehen, wo ich mich dann um nix kümmern muss? Ich bin absolut Deiner Meinung. Einfach zurücklehnen und genießen.
Tja, warum macht also Sumpfdotter das also plötzlich? Vielleicht hat es ja ein kleines bisschen damit zu tun, dass meine Daten auf dem RAID1
und
auf der Backup-Platte durch QTS zerstört wurden? Oh die Frage kam schon vor drei Wochen: Wende Dich doch einfach an den Support! Warum machst du deren Arbeit? Stimmt! Das war auch eine fantastische idee. Mein Ticket liegt längst beim QNAP-Support - seit 3 Wochen ungelesen. (Ergänzung: Christian hatte spontan diverse Aspekte per "Fastlane" an die Entwickler gereicht, vielen Dank dafür!!) Also warum macht Sumpfdotter das eigentlich? Das frage ich mich ehrlich gesagt auch ...
Völlig korrekt UpSpin! Ich mag die vielen Features des QNAP. Also, tja, warum schaue ich mir das alles an?
Seit 3 Wochen schaffe ich es nicht, mein QNAP so aufzusetzen, dass ich endlich wieder ein Backup meines Arbeitsrechners darauf speichern kann. Zuerst nahm ich das 0551. Eine ungute Idee. Dann also alles nochmal mit dem 0515. Da ging aber auch was schief: Ich testete zuvor meine RESTORE-Stategie! (Viele Grüße an @oerus ;-)) Und ich stellte fest: Thin-Provisioning war keine gute Idee! Das proprietäre LVM2-Format von QTS kann ich im Ernstfall mit Linux nicht restaurieren.
Also nochmal aufgesetzt - ab sofort nur noch ohne Thick und Doof. Gestern war es endlich soweit, dass die (hoffentlich) geretteten Daten wieder aufs QNAP gespielt werden wollten. Dann plötzlich hagelte es aber Read-Errors. Filesystemfehler. Auf einem frisch aufgesetzten NAS (d.h. zuvor war NV-RAM zurückgesetzt, Firmware war frisch eingespielt und Festplatten-MBR war geleert - frischer geht es nicht?). Womöglich habe ich schon wieder einen Fehler gemacht: Nach dem das RAID synchroniert war, die Platten heruntergefahren waren, die LEDs aus waren, hab ich versehentlich ohne Runterfahren den Stromstecker gezogen. Ein normales Linux hätte das überlebt. Nun habe ich das QNAP schon wieder neu eingerichtet. Blöderweise habe ich vergessen die HD-Station zu installieren, d.h. das Ding bootet jetzt nicht mehr. Ich bin aber auch echt ein Dussel, oder?
Stimmt also: Eigentlich "kann es mir ja komplett egal sein, wie QNAP seine Systeme aufbaut" ...
BTW, Snapshots wurden in aktuelleren Kernels für ext4 von der Community hinzugefügt (habs vor nicht allzu langer Zeit irgendwo gelesen). Was QNAP da vermutlich versucht, ist das Rückportieren in ihren älteren Kernel-Stand. Besser wäre es gewesen, man aktualisiert auf einen neueren Kernel, aber das wird umso schwerer, je mehr man dran rumgebastelt hat. Dann hätten sie es auch einfacher, Sicherheitsfixes wie für Spectre zu bekommen, denn bis jetzt gibt es darüber immer noch nichts Neues von QNAP.
Hi warpcam! Ein Backbport wäre ja noch schick. Aber googelt einfach mal selber nach type "thin-pool" (original LVM) und dann nach type "tier-thin-pool" (QTS-only?). M.E. gibt es das Format in Linux nicht. Und bestätigt werde ich hierduch:
QNAP NAS RAID-Systeme verwenden nicht das Standard-Linux Thin Provisioning, sondern ein von QNAP proprietär adaptiertes Thin Provisioning.
D.h. zur Datenrettung muss man entweder ein QNAP-System verwenden (sofern man eben eins hat, das funktioniert), oder jeder muss schauen, ob er ...
so tief in die Materie einsteigt
Hallo,
der Thread ist ziemlich lang, muss ich sagen D.h. ich konnte nicht jeden Beitrag lesen. Nun, ich habe ein anderes NAS, das TS-251+. Allerdings habe ich ähnliche (gleiche) Symptome: Das NAS fährt nicht sauber hoch: Kein Ping, kein Netzwerkverhalten. Und dann fiel mir plötzlich auf, dass es womöglich dann verursacht wird, wenn die HD-Station nicht installiert ist, und gleichzeitig kein Bildschirm (und/oder Maus/Tastatur?) angeschlossen ist. Dann fährt es nicht hoch.
Nachtrag: In dem Zustand klappt dann übrigens auch nicht das Shutdown via Power-Button.
Kennt das jemand so? (beobachtet 4.3.4 515 sowie 0537)
VG
Holger
Ich empfehle einmal per ssh auf das NAS zu gehen, in das entsprechende Oberverzeichnis zu navigieren, könnte ungefähr so lauten:
cd /mnt/INTENSO/backup/Planer/Mail/Profiles/vt9ufgbp.default/Mail/
Und dort dann den Befehl "ls -al" auszuführen, und insbesondere auf die angezeigten Attribute vom Ornder postbote-3 zu achten: Sind die Attribute überhaupt angezeigt, oder sieht man da "???" (Fragezeichen). Wenn alles korrekt ist, einfach mal "ls -al postbote-3" machen, um zu schauen wie "ls" reagiert, wenn man in den Ordner hineinguckt.
Hallo,
leider konnte offenbar noch niemand etwas zu den offenen Fragen sagen. Für alle, die eventuell später hier landen:
Mein Analysen breche ich an der Stelle an. Ich habe den letzten öffentlichen Stand der QTS-Sourcen (Februar 2018) mit dem zugehörigen Original-Kernel verglichen. QNAP macht nach meiner Auffassung einige Änderungen an ext4, z.B.:
Im Ergebnis habe ich in meinen Test stets einige Kniffe zu tun, um QTS-Volumes mit Linux zu mounten und umgekehrt. Und ich ahne, dass man besser keine Schreibzugriffe auf so "über kreuz" gemountente Volumes durchführen sollte - insofern man einen RW-mount denn hinbekommt.
Leider brauche ich für meine Daten einen Speicher, der zuverlässig funktioniert und im Ernstfall mit Standardtools abgerufen werden kann. Deshalb sind mir das in Summe zu viele Anpassungen. Allein der Source-Code "super.c", der die ext4-Metadaten beschreibt, hat 76 Änderungen gegenüber dem Original-Kernel bzgl Quota, Journal, ACL, Read-Only-Mode, Case-Insensitivität, Lazy-Init, Trim, Fehler-Handling, Ejection oder HAL. Darunter auch neue Flags, die IDs belegen, wo ich nicht herausfinden konnte dass diese für eigene Benutzung reserviert seien. Bei inode.c geht es dann weiter mit 46 Änderungen usw.
Ich denke soweit reicht es aus, dass ich mir ein Bild machen konnte. Nichtsdestotrotz würde mich immer interessieren, inwieweit andere Nutzer Inkompatibilitäten erleben oder eben - sehr interessant - Workarounds dafür darstellen.
