Beiträge von Sumpfdotter

Das TS-251+ ist doch ein x86 mit HDMI und Bios. Das kriegt man doch garnicht "gebrickt" (außer vielleicht durch ein BIOS-Update)?

- Bildschirm anklemmen

- Tastatur anklemmen

- Anschalten

- Immer und immer wieder <Del> drücken

Dann müsstest Du ins BIOS kommen. Falls das klappt, hast Du doch eine Chance. (Falls nicht, ist doch die Hardware im Eimer, oder sehe ich das falsch? Du schreibst, Du hast echt kein BIOS-Zugang mehr?)

Also falls doch, obwohl Du das wohl weißt:

Irgend eine schlanke Linux-Distri, z.B. einfach den Arch-Linux-Installer, auf USB-Stick ballern, den Stick anklemmen, im Bios als Boot-Medium auswählen und das Linux booten. Dann besorgst Du Dir ein valides DOM-Image (m.W. immer noch die 1.3.0) und bügelst das wieder auf das DOM-Laufwerk drüber (dd if=<meinImage> of=/dev/disk/by-id/<DOM-LW>;sync), am besten machste noch die Root-Sektoren der internen Platten platt, damit der Installer sie nicht mehr erkennt (Backup vorausgesetzt ;-), neu booten (ohne Stick, vom DOM), installieren, updaten, zur Sicherheit nochmal factory-reset und 10-Sekunden-Reset (weiß jemand, was der technisch genau so treibt? ... freuen.

Achso: Ich war mir bei Deiner Beschreibung nicht sicher: Du glaubst wirklich, das DOM sei hardwaremäßig defekt? Dann würde das o.g. recovery natürlich nicht helfen, weil Du ja schlecht den Installer auf das defekte DOM schreiben kannst. Das wäre einzusehen. Aber: Das BIOS zeigt das DOM ja nur an, wenn auch eine Boot-Partition drauf ist. Und das wäre ja bei hardwaremäßig intaktem DOM sofort geheilt, wenn du das richtige DOM-Image (s.o.) wieder aufgespielt hast. Das enthält ja die Boot-Partition, logischerweise. Also ich würde das mal aufspielen, und gucken, ob das BIOS mir das DOM dann wieder zum Booten anbietet.

Ob das DOM defekt ist, kannst Du doch vielleicht auch vom Linux aus mal testen. Entweder Linux erkennt es schon nicht (defekt?). Oder falls doch, schreibste irgendwelche Testdaten drauf (z.B. das korrekte Image) und liest sie wieder aus ... ? (Vorher ein Image als Backup ziehen ist übrigens immer eine gute Idee) Prüfsumme machen, vergleichen.... irgendwie so halt. Wenn das aber alles klappt und korrekt ist, müsste das Teil doch auch mit dem passenden DOM-Image zum Booten zu bewegen zu sein?

Jedenfalls hätte ich, falls das DOM total hin ist, und auch vom Linux nicht erkannt wird, dann noch die Idee, dass Du einfach das DOM-Image nicht auf's DOM, sondern mal auf 'nen Stick brummst und bootest. Da brauchste erstmal nix löten. Das Ding hat doch Slots ;-)) Hat das mal einer probiert? Vielleicht wird der Stick dann nicht als /dev/sdc eingebunden. Ist dann die Frage, ob man das dem Installer/Laufzeitsystem verklickern muss und kann. Aber vielleicht reicht ja eine Datei auf der 6. Partition, da hab ich nämlich folgenden Inhalt:

[System]
Model = TS-X51
Internal Model = TS-X51
Server Comment = NAS Server
Version = 4.4.1
Build Number = 20191206
Number = 1146
Time Zone = Europe/Amsterdam
Enable Daylight Saving Time = TRUE
Workgroup=NAS
Code Page = 437
System Device = /dev/sdc
...

Man achte auf die letzte Zeile. Vielleicht kann man hier ja das System-Device umbiegen, sollte der Stick nicht auf sdc zum liegen kommen. Ist hoffentlich kein Henne-Ei-Problem ...

Ich wiederhole den Tipp: Schau doch erstmal, welche Prozesse gerade laufen. Dann ist vielleicht ersichtlich, wo er hängt. Die beste Möglichkeit, sich die Prozesse anzuschauen, kenn ich jetzt nicht. Ich hab per ssh ne Shell aufgemacht und per "top" geschaut und hatte Glück, dass der hängende Prozess aufgrund seiner Rechenleistung gleich oben stand. Siehe oben. Du kannst vielleicht auch mit "ps" mal schauen, oder gibt es nicht auch noch dieses "pstree" oder so, wo man die Prozesshierachie sehen kann? Das könnte auch helfen.

Achso, andersrum. Nicht die Partition wird verschlüsselt, sondern erst ein unverschlüsseltes Dateisystem, und darin dann eine Datei mit dem verschlüsselten Backup ... dann müsste man natürlich wissen, was die Datei für ein Format hat, und dafür dann ein Anwendungsprogramm haben. Verstanden.

Zitat von Mavalok2

Kein Wunder, das FAT Filesystem beherrscht keinerlei Berechtigungen und so gut wie keine Attribute.

Eben drum kommt sie ja wohl.

Zitat von Santamaria13

Kann jemand sagen, welche Daten oder Attribute hier gemeint sind und wie ich diesen Fehler weg bekomme?

Naja ... über SMB? Da kann man wohl nicht alle Unix-Dateiattribute übertragen ... da bleibt einiges auf der Strecke. Ggf. owner, group, mode, ... keine Ahnung. Ich kenn die Beschwerde auch, aber in dem Zusammenhang, wenn ich versuche auf ein FAT-Lauferwerk zu kopieren ...

Zitat von Jagi

Ist das selbe in grün was man jetzt auch mit Qnap machen kann.

Okay, nochmal zum Mitschreiben für mich als Dummi. Das Syno-Tool Hyper-Backup-Explorer ist also ein frei verwendbares Tool, was generell LUKS-Format entschlüsseln kann und darin befindliche NFTS-Systeme auslesen kann? Und deshalb kann man es auch für beliebige LUKS&NTFS-formatierte Medien verwenden, auch für welche, die man mit QTS bespielt hat?

Zitat von Jagi

Formatiere die Festplatte in einem Format was dein Mac und Qnap lesen kann.

Äh, das war jetzt ein Scherz, oder? Mit ist kein Verschlüsselungsformat bekannt, das beide können. Bei QTS kenne ich nur LUKS, und LUKS wird von Mac nicht unterstützt. Was man meistens als Lösung liest, ist eine VM zu verwenden. Vielleicht wäre es auch eine Idee, auf QTS eine VW zu starte ...

Zitat von christian

Hinzu kommt, dass das Problem zumindest in Verbindung mit der externen USB Festplatte auftritt, somit verstehe ich die Aussage vom Support schon.

Hm. Was meinst Du denn mit "Hinzu kommt"? Ich hatte das Gefühl, dass dieses Argument garnicht "hinzu kommt", sondern dass das von vorne herein der Diskussionspunkt dieses Threads ist: Ablenkung vom eigentlichen Problem, anstatt zu helfen, es zu lösen.

Beispiel: Fast alle Probleme, die mit dem QNAP auftreten, basieren natürlich darauf, dass Software ausgeführt wird. Und dazu braucht man Hauptspeicher. Also könnte man jeden einzelnen Hilfesuchenden, egal welches Thema, erstmal zurückweisen: Hast Du einen kompatiblen Hauptspeicher?

Lass uns mal versuchen, den Blickwinkel nur einmal für diese Diskussion umzudrehen. Denn mein Gefühl ist, dass ich es regelmäßig nicht nur vom Support, sondern auch hier im Forum erlebe. Auch an mir selbst, so wie z.B. hier. Für den Hilfesuchenden ist das kein schönes Gefühl. Der Hilfesuchende muss sich sofort verteidigen, so wie hier. Dann wird der Thread auch noch gerne verrauscht, so wie hier ... und am Ende auch noch geschlossen, ohne dass der Fragesteller Hilfe bekommen hat, so wie hier.

Insofern hat der Hilfesuchende gleich zwei Probleme: Der Support hat ihn abblitzen lassen. Und das Forum dann auch noch. Abgeblitzt mit Argumenten, die mit seinem Problem nichts zu tun hatten. Warum geschieht das so?

Du hast geschrieben, man disqualifiziere sich hier im Forum, wenn man sowas hier vorträgt. Wahrscheinlich kommst Du auch zu dem Schluss, dass Du da - so wie es mir auch gerne mal passiert - emotional etwas über das Ziel hinausgeschossen bist. Denn der betroffene User fühlt sich sicher auch nicht so super, wenn er das so über sich lesen muss. Aber auch inhaltlich hat dieser Thread doch durchaus etwas zu bieten, denn wir alle haben etwas gelernt: Bloß nicht beim Support die konkrete Hardware korrekt angeben, das hilft.

Oder hast Du das ernst gemeint, als Du gerade empfohlen hast: Auf @jantse hören, und Zyxel nehmen ...

Zitat von janste

QNAP gibt nicht umsonst solche Kompatibilitätslisten heraus

Noch viel mehr als über diese Unart sowohl hier als auch bei QNAP, dass man aus der Diskussion geworfen wird, wenn angeblich irgend eine Stromwelle aus dem 230V-Netz leider Ökostrom war, oder wenn man blöderweise sein Frontend von der Südhalbkugel gestartet hat, noch viel mehr wundere ich mich darüber, dass User hier im Forum dieser Praktik auch noch beipflichten.

Der Hauptpunkt ist doch, dass die angeführten Probleme garnicht im Bezug zur monierten Abweichung stehen, davon abgesehen, dass Standards eben dafür da sind, Querverbaubarkeit herzustellen. Und beim besten Willen, dass ein Backup-Scheduling nicht funzt, hat nun wirklich nix mit der verwendeten Platte zu tun. Diese ewigen Ablenkungsmanöver hier im Forum genauso wie bei QNAP selbst: Sie nerven, weil sie diejenigen, die Hilfe geben könnten, von denen fernhalten, die sie brauchen.

Zitat von Unrealswebmaster

Erst mit cat /proc/swaps den Namen der Partition herausfinden und danach mit swapoff /dev/md256 (md256 ist mein Name der Partition) deaktivieren.

Nachdem ich auf meinen verschlüsselten Festplatten die Tage bei nem Scan dann doch Nutzdaten gefunden hatte - natürlich auf der Swap-Partition, will ich die jetzt auch ausschalten.

Spitzen Tipp! Das werde ich ausprobieren.

Kann jemand berichten, ob es vorgekommen ist, dass ein Firmware-Update das Swapping wieder eingeschaltet hat?

Nachtrag: Hilfe! Ich bekomme es nicht hin!

Wenn ich swapoff mache, oder gar mdadm -S, nach einem Reboot ist das Swapping immer wieder an! (mit aktueller FW für TS-251+: 4.4.1.1146)

Hat einer einen Tipp, wie man es dauerhaft ausgeschaltet bekommt? Oder alternativ, wie man Crypto darauf enabled (was sicher nicht so einfach wäre)??

Zitat von RedDiabolo

Na ja, QNAP geht davon aus, dass JEDES Update wichtig ist und die User es auch durchführen.

Stimmt übrigens nicht. Wie ich gerade sehe, zeigt das NAS folgenden Text an:

Bildschirmfoto 2020-01-17 um 00.20.58.png

Zitat von Wumba

Bei 75% bleibt das Ganze allerdings stehen, auch nach 24h hat sich nichts getan.

Vor knapp zwei Jahren gab es mal die Katastrophen-Firmware, die sich ähnlich verhielt. Sie blieb bei ca. 68% stehen, und am Ende war das Filesystem zerschossen. Dummerweise war das auch nicht sofort erkennbar, sondern konnte sich durchaus auch auf's Backup auswirken - wenn man so "doof" war, mit der Firmware auch noch zu arbeiten und dann auch noch das Backup-Laufwerk anzuklemmen.

Ich hatte damals glaube ich per Kommandozeile (ssh) nachgesehen, was er gerade tut. Und dabei stellte sich heraus, dass bei der Prozentzahl ein Thumbnail-Remove-Befehl lief, der sich aufgrund des Dateisystem-Fehlers aufgehängt hatte: hab's eben wieder gefunden: klickst Du hier

Wenn das bei Dir auch so sein sollte, lohnt sich vielleicht, das Dateisystem einmal "echt" auf Konsistenz zu prüfen. Ich würde das Medium ausbauen, und mit Linux ein Backup machen (geht aber nur bei static Volume, nicht bei Thin/Thick Provisioning). Alternativ ein Image. Danach kann man versuchen, das Filesystem mit den QNAP e2fsck per Kommandozeile wieder zu fixen und sich die Ausgaben dabei auch anzuschauen. (Achtung: das e2fsck von QNAP macht per Default Schreibzugriffe!) Das Problem ist: Qnap hält sich nicht an den ext4-Standard. Und ihr eigenes e2fsck kennt noch nichtmal ihre eigenen Patches am ext4 und meckert selber diese Sachen (konkret die missbrauchten htree-Einträge) selber als Fehler. Aber bei mir ging es immer trotzdem zu "reparieren" - obwohl ich mir nicht sicher bin, ob dadurch nicht gerade Performance-Einbuße bei Sparsebundles (ca. 500k Files in einem Ordner) herrühren könnten.

Du hast echt keinen Schimmer, oder? Das ist im original LVM auch drin. Wir suchen die Sourcen eben nicht zu "Thin-Pool" und nicht zu "Tiering", sondern zu "tier-thin-pool". Weil genau die gebraucht werden, um das zu tun, was der Fragesteller in diesem Tread möchte!

Warum kannst Du nicht einfach die Größe zeigen und sagen: "Tut mir leid, ich habe keine Ahnung von dem Zeugs. Finde es toll, dass ihr darüber quatscht." Nein, Du musst den Thread ablenken und immer wieder eins nachlegen, so dass andere Dich immer wieder widerlegen muss, damit ein Nachkömmling nicht auf Deine Masche reinfällt. Fehlt nur noch, dass Du fragst, welche Speicherriegel der User verbaut hat.

Zitat von dr_mike

Wie gesagt - wenn du Meister in Kernel-Programmierung bist, dann sollte es dir nicht schwer fallen herauszufinden wo das passiert.

Ich habe nicht behauptet, dass die Sourcen öffentlich sind, sondern Du warst es. Es wäre so einfach sich rauszuhalten oder irgendwann nach Erkenntnis einfach zu sagen: "Ich muss meine Behauptung zurückziehen, ich weiß nicht, ob die einschlägigen Sourcen öffentlich sind." Das wäre alles, was zu tun ist. Du beharrst lieber darauf, einen anderen User als unfähig zu denunzieren. Wenn das ein Moderator mal sähe ...

Zitat von dr_mike

Sorry, dass ich es so sagen muss, aber du bist (milde ausgedrückt) doch nicht in der Lage selbst nachzusehen.

Schon wieder beleidigend? Wieder einen wunden Punkt getroffen? Was willst Du mit den Screenshots jetzt aufzeigen? Ein paar Verzeichnisinhalte auflisten sollte wohl noch so mancher hinbekommen. Liefere endlich den Beweis. Wo sind Deiner Meinung nach jetzt die Sourcen vom "tier-thin-pool"? Meinetwegen als konkrete Aufgabe: Zeige mir die Stringkonstante "tier-thin-pool", die QTS auf die Platte schreibt.

Solange Du das nicht kannst, darfst Du hier nicht behaupten, die Sourcen seien öffentlich und ich und andere nur zu (weniger milde ausgedrückt) blöd. Du lenkst ab. Und das nervt einfach, weil Du die sinnvollen Postings wegrauschst.

Zitat von dr_mike

Um diese Sourcen ging es ja auch nicht.

Aha. Grübel, was meint Doktor Mike denn dann? Mal eben zurückblättern im Forum: Der Fragesteller will wissen, wie man ohne QNAP-Hardware, und damit auch ohne QTS, an die Daten rankommt. Und da gibt es ein Problem:

Zitat von Sumpfdotter

QNAP hat LVM2 um einen eigenen, proprietären Segment-Typ "tier-thin-pool" erweitert (siehe hier)
QNAP hat den Source-Code dazu nicht freigeben (siehe hier)

Ergo: Natürlich ging es um genau diese Sourcen. Und ich denke, das weißt Du auch. Was willst Du mit Deinen Aktionen bezwecken? Gibt endlich einen Link auf das entsprechende Source-File raus, das ja Dir zu Folge irgendwo in dem von Dir verlinkten Source-Tree liegen muss. Es hat doch niemand davon gesprochen, einen Patch zu bauen. Wir wollen nur die Sourcen sehen. That's it. Beweise Deine Aussagen, und wir können endlich daran arbeiten unsere Daten zu interpretieren, oder erkenne an, dass QNAP dieses proprietäre tier-thin-pool-Zeug vermutlich gegen GPL-Recht geschlossen hält und erspare uns bitte weitere unqualifizierten Kommentare. Diese Ablenkungsmanöver nerven und spammen die interessanten Sachen weg. Vielleicht willst Du genau das ja bezwecken.

Zitat von dr_mike

Ich dachte du bist selbst in der Lage, auf der QNAP-Homepage nachzuschauen. Scheinbar nicht.

Du hast keine Ahnung, dass da die Sourcen zum "tier-thin-pool" gar nicht liegen, nicht wahr?

So einfach ist es, Dich dazu zu bringen, mich zu beleidigen? Wow.

Jetzt bin ich mir ziemlich sicher, dass Du immer wieder versuchst, mit unsinnigen Quermails von dem Problem abzulenken. Sonst könntest Du hier einfach einen Link auf das entsprechende File posten. Machst Du aber nicht. Schade, dass diese Stilmittel hier für mein Gefühl so oft angewendet wird. Fehlt nur noch, dass wieder einer fragt, welche Speicherriegel der User eingesetzt hat.

Hi Dr_Mike,

Zitat von dr_mike

Die Quellen liegen immernoch an der selben Stelle wie eh und je.

bzgl.

Zitat von Sumpfdotter

Bitte postet doch einfach mal jemand, der sowas behauptet, einen Link auf die Sourcen zum "tier-thin-pool". Punkt. Diese Ablenkungsmanöver nerven mich.

Kommt da noch was? Ein Link würde mich wirklich sehr freuen ... wäre durchaus hilfreich für Datenrettung und damit für die Backup-Strategie.

Zitat von Mehran

zwei Platten WD Red 4TB Typ WD40EFRX

Ein RAID1 mit nur 4TB? In dem Falle könnte man ja erwägen, ein Image einer Platte zu ziehen? Muss man eigentlich auch die alte Firmware für's Rollback parat haben (weil auf der DOM gespeichert), oder bootet das System nach der Installation von den Platten?

Zitat von u33bipp

Was soll eine Verschlüsselung der Platten überhaupt bringen?

A) Jemand klaut Deine Platte oder das NAS (Natürlich sollte für letzteres der Key nicht vor Ort sein; da gibt es komfortable Möglichkeiten. Z.B. USB-Stick in der Wand verbaut, oder Key auf Web-Server im Internet ... denk Dir was aus

B) Du willst die Platte mitnehmen (Ich nehme immer eine mit in Urlaub)

C) Du willst die Platte loswerden (die Zeit kommt irgendwann)