Beiträge von itbastler

    hm ... ja, klar, überschreiben geht immer ... dauert je nach Größe halt - und auch nur, wenn die Platte noch richtig funktioniert.

    Die rustikale Methode wollte ich mir eigentlich sparen ... Und in eurer Firma werdet ihr die HDD sicher auch irgendwie richtig entsorgen.


    Im Moment ist eh das Problem, dass beim Booten die Platten nicht richtig entsperrt werden - nur einmal hat es geklappt, dass omv 3x nach einem Passwort gefragt hat - jetzt nur noch 1x und 2 oder auch alle 3 Platten werden nicht entsperrt ... ist doch ein Krampf...

    Hi,

    ich würde mir eher Sorgen machen, ob so etwas Sozial-/Beziehungskompatibel ist ;-)) (oder ist es eine Männer-WG?)


    Aber ernsthaft: Weshalb in die Küche? M.E. der schlechteste Platz - schon wegen Küchendämpfen etc. Auch würde mich mir den Streß mit Umbau, Schrank beschädigen/extra kaufen, Belüftung etc gar nicht antuen. Habt ihr nicht einen Platz, zB wo ohnehin das Telefon, fritzBox o.ä. stehen - da würde so ein kleines NAS doch locken hinpassen? Es gibt doch auch so kleine Schänkchen/Tische(mit innen Stauraum), die quasi komlett aus so einem Art Holzgitter bestehen (Alternativ: evtl. die Rückwand von einem "nomalen Schränkchen ersetzen/modifizieren)


    Also zB so was - ist jetzt zwar nicht genau das, was ich gemeint habe und natürlich Geschmackssache:


    https://www.amazon.de/Rebecca-…nk&qid=1621071288&sr=8-50

    https://www.amazon.de/HOOBRO-B…nk&qid=1621071288&sr=8-21

    https://www.amazon.de/VASAGLE-…3%A4n%2Caps%2C186&sr=8-63


    Da dann noch die Rückwand etwas modifizieren / da wo das NAS steht (Löcher/Gitter), dann sollte das doch passen...

    ok ... scheint eher ein generelles, bekanntes Problem zu sein - k.A. weshalb es bisher nicht aufgefallen ist ... evtl. nie rebootet...


    https://www.bananatronics.org/openmediavault-issues/

    https://forum.openmediavault.o…unionfilesystem/&pageNo=1


    Also grob offenbar die Abhängigkeiten / versuch, automatisch die Laufwerke einzubinden, die aber noch nicht "da" sind weil verschlüsselt ... etwas unschön, da m.E. so nach dem Entsperren der Pool auch nicht autom. verfügbar ist, erst wenn ich einmal die config neu schreibe ...


    Hier habe ich sogar eine Anleitung gefunden, wie man die Probleme vermeidet - Nachteil für mich: Man müsste ja auf die Konsole zugreifenm, was ich eigentlich nicht wollte (bzw ohne Passphrase entsperren, will ich natürlich auch nicht):

    https://forum.openmediavault.o…th-mergerfs-snapraid-too/


    Jedenfalls hat mich das Ganze auch wieder an meine Grundsatzfrage denken lassen, ob ich die Platten überhaupt verschlüsseln will ... Vor-/Nachteile.

    (Großer) Nachteil: man kommt im Fehlerfall evtl. nicht mehr ran, Vorteil - wenn eine Platte verstirbt, ausgetauscht wird o.ä. muss man sich bei der Entsorgung keine/weniger Gedanken machen, ob/was da ggf noch (unverschlüsselt) drauf sein könnte.

    Also normal war/sollte es so sein: System bootet (Systemplatte ist ja nicht verschlüsselt) - ich gehe auf die Gui und entsperre die verschlüsselten HDDs.

    Danach sollte der Pool da sein.

    Hatte die Anleitung https://michaelxander.com/diy-nas/ befolgt.


    Wenn ich in der fstabl die Zeile, in der auf die mergerfs-config mit den 3 HDDs verwiesen wird (ich verstehe es so, dass das das Pool-LW ist), dann bootet das Sysem normal.


    Kleiner Unsicherheitsfaktor: ich kann nicht 100% garantieren, dass ich das System überhaupt schon mal neu gestartet habe, seit ich es so eingerichtet habe. D.h. könnte sein, dass es gar nichts mit dem hart ausschalten zu tun hat ... das nur am Rande ;-)

    du kannst dir mal anschauen, was blkid für diese Platten sagt. Hoffen wir, das da was angezeigt wird, was vernünftig ist.


    vermutlich wurde durch das harte Ausschalten bei diesen Platten der Anfang überschrieben. Dann kannst du fast nichts mehr machen.

    Hi, danke erstmal für den o.g. Befehl. Zum einen sieht der Output doch grundsätzlich ok (?) aus? zum Anderen hatte ich die Partitionen wohl verschlüsselt ...


    Code
    /dev/sdc: UUID="6596afed-40c5-475f-9640-99d5ed73090a" LABEL="data01" TYPE="crypto_LUKS"
    /dev/sdd: UUID="49236203-6fe4-4079-be28-0a62749efe20" LABEL="data02" TYPE="crypto_LUKS"
    /dev/sda1: UUID="517b113a-cf32-4ebc-9fda-e0221f4dbd77" TYPE="ext4" PARTUUID="4e951206-01"
    /dev/sda5: UUID="5a320681-292a-461f-8be7-690be2e1a3cb" TYPE="swap" PARTUUID="4e951206-05"
    /dev/sr0: UUID="2020-03-25-16-03-59-00" LABEL="openmediavault 20200325-17:17" TYPE="iso9660" PTUUID="c39bfd10" PTTYPE="dos"
    /dev/sdb: UUID="69bdcef7-f9bb-47f0-8cc9-a3ddda6f45f7" LABEL="parity01" TYPE="crypto_LUKS"

    Kann aber die Platten nicht ensperren ... außerdem wundert mich dass das System nicht starten wollte (es sind ja nur Datenplatten).

    In der fstab fide ich die o.g. uuids auch nicht:


    Code
    # >>> [openmediavault]
    /dev/disk/by-uuid/9c35bb4e-c9ef-4d02-8499-a0d4d76ea1e0          /srv/dev-disk-by-uuid-9c35bb4e-c9ef-4d02-8499-a0d4d76ea1e0      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
    /dev/disk/by-uuid/739328ca-fe8b-4fa0-95e4-6970eed6e14d          /srv/dev-disk-by-uuid-739328ca-fe8b-4fa0-95e4-6970eed6e14d      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
    /dev/disk/by-uuid/a67d91bd-83dd-4f7f-a051-478a578fa9b8          /srv/dev-disk-by-uuid-a67d91bd-83dd-4f7f-a051-478a578fa9b8      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
    ##/srv/dev-disk-by-uuid-739328ca-fe8b-4fa0-95e4-6970eed6e14d:/srv/dev-disk-by-uuid-a67d91bd-83dd-4f7f-a051-478a578fa9b8         /srv/aa106867-1f5e-4036-94f4-f258c8c06f61       fuse.mergerfs   defaults,allow_other,cache.files=off,use_ino,category.create=epmfs,minfreespace=100G,fsname=pool01:aa106867-1f5e-4036-94f4-f258c8c06f61,x-systemd.requires=/srv/dev-disk-by-uuid-739328ca-fe8b-4fa0-95e4-6970eed6e14d,x-systemd.requires=/srv/dev-disk-by-uuid-a67d91bd-83dd-4f7f-a051-478a578fa9b8     0 0
    # <<< [openmediavault]


    Bin leider völlig überfragt :-)

    Hallo,


    OMV läuft bei mir als VM auf einem ESXi

    Die 3 HDDs werden an die VM durchgereicht, in dem ich den ganzen Controller durchreiche.

    Habe Mergerfs drauf eingerichtet bzw damit eingebunden.


    Nachdem ich den ESX und/oder die VM hart ausgeschaltet habe, booten OMV in den emergency mode.


    open pipe file /run/rpc_pipefs/nfs/blocklayout files: No

    ...

    Timed out waiting for device /dev/disk/by-uuid/a67....

    weiter unten dann diverse "dependency failed for (o.g. Disk)" Fehler


    wiederholt sich m.e. auch für die anderen beiden HDDs (sind 3).


    wenn ich in /etc/fstab die Zeile /srv/dev-disk-by-uuid.... auskommentiere, bootet OMV zumindest, allerdings sind dann eben die Platten nicht da.

    Dh die physischen Platten sind schon da, Smart-Werte alle ok etc - aber die logischen nicht. Ich könnte sogar unter filesystem sie auswählen, um ein neues FS drauf einzurichten, was ich natürlich nicht gemacht habe.


    Kann es sein, dass die UUID irgendwie anders ist oder so erwas?

    Das kleine Problem bei der Verschlüsselung ist, dass sobald der Rechner hochgefahren ist, alles entschlüsselt daliegt. Dann hängt alles nur noch an dem Passwort, dass genügend stark sein muss, damit man (hier der Dieb, oder ein zu neugieriger Verwandter) dann nicht an die Daten kommt.
    Da hat ein verschlüsselter Container schon seine Vorteile, da er (eigentlich) nur bei Bedarf geöffnet wird und durchaus hinterher wieder geschlossen werden kann. Da liegen die Daten dann nicht offen herum wie auf dem Präsentierteller.

    Ich kenne LUKS zwar nicht im Detail aber wie bei anderen ähnlichen Systemen, ist die Platte im gemounteten/entsperrten Zustand dem OS gegenüber transparent. Es geht hier ja um Diebstahl o.ä., dh im ausgeschalteten Zustand - Jemand muss ja den Sever abbauen um ihn zu klauen (ja, ich weiß, es gibt Methoden den ohne Stromunterbrechung fort zu tragen ...). Und automatisch wird da ja nichts entsperrt, da muss man schon das HDD-Kennwort eingeben.
    D.h. jetzt nicht unsicherer wie das verschlüsselte BAckup auf einer externen HDD - oder ein Container. Übrigens könnte auch bei letzterem ein Trojaner auf den Inhalt zugreifen, sobald du ihn entsperrst oder eben das Passwort mitloggen.

    wb


    Das o.g. war von mir evtl. etwas missverständlich / stark verkürzt geschrieben. Vollständig ging der Gedanke etwas so: Backups, die zB vom PC autom. laufen und auf dem NAS abgelegt werden, könnte man ohnehin verschlüsselt ablegen oder würde es ohnehin, weil man die ggf zusäzulich noch auf eine extrene Platte, Cloud o.ä. speichert. D.h. dafür würde es jetzt nicht so viel Sinn machen, auch noch die HDD zu verschlüsseln.
    Was ich mit Smartphone etc meinte war: klar schützt das nicht die Daten auf dem Smartphone. Ging eher darum, wenn man da über eine einfache Sicherungssoftware, von Hand oder wie auch immer Daten "einfach so" auf das NAS kopiert/sichert - sind die DORT eben im Falle eines Diebstahls ebenfalls gesichert.


    Aha - ist LUKS dann eher wie EFS? dachte es wäre Sektorbasierte Diskverschlüsselung. Das erklärt auch, weshalb die Initialisierung so schnell fertig war ...


    D.h. deine Nextcloud verwendet nicht die Daten-Disks? Sondern ist ein anderes System/extern/etc? Ist das eine VM oder bringt Nextcloud unabhängig vom Unterbau so eine Funktion mit?

    Wenn man jetzt einen verschlüsselten Container (aus meiner Sicht praktikabler als jede Datei einzeln zu verschlüsseln) hat, dann ist das aus OS-Sicht ja nur ein großer Datenblob. Die Frage ist dann auch, welches Passwort du dafür nimmst. Sollte ja, wenn man es ernst meint, nicht das Anmeldepasswort sein. Dann kommt da noch der Punkt der Sicherung. Der Container wird gerade am Anfang recht Ineffizient sein (kenne das noch aus der Zeit, als wir vertrauliche Daten in TrueCrypt-Containern auf USB-Sticks ausgetauscht haben; Da war dann halt Containergröße==USB-Größe egal was im Container war).

    ähm ... nein ;)


    also ... Dateiverschlüsselung ist in diesem Fall natürlich nicht jede Datei einzeln (von Hand) - im Prinzip ist auf dem zB PC ein Client installiert, der sich im Hintergrund um die tranparente Ver-/Entschlüsselung kümmert - natürlich nur, wenn du dich entsprechend angemeldet hat + berechtigt bist. Was verschlüsselt wird, regelt eine Policy und wer (dh welche Keys) Zugriff haben, regelt ggf. der "owner" der Daten. Ver/Entschlüsselung ist blockbasiert und wenn man so will, nur der jeweilige in/output - es wird also nicht die Datei "auf dem Server" entschlüsselt, nur weil du die lesen oder bearbeiten willst. Für den Anwender + das OS ist es völlig transparent. Multi-User ist daher auch kein Problem.


    Container: wie gesagt - den hatte ich gedanklich ohnehin in den Bereich Homeuser oder Verlegenheitslösung verbannt. U.a. kein Multi-User/gleichzeitiger Zugriff, anfälliger (Container defekt, alles pfutsch...).
    Allerdings gibt es auch bei Containern die Möglichkeit, diese mitwachsen zu lassen ... bis z.B. einer max. Größe. Er belegt dann eben genau nicht sofort 1 GB nur weil du da ein Worddokument drin gespeichert hast.


    Spoiler: ich werde voraussichtlich doch die HDDs verschlüsseln - nach nochmaligem Test macht es auf meinem System offenbar 0 Unterschied bezgl. Performance. Daher schadet es eigentlich auch nicht und man hat so auch einen Schutz von Daten, die evtl. von anderen Geräten kommen, vielleicht Smartphone-Backup oder k.a. - die die Verschlüsselung sonst nicht unterstützen.

    Hi,


    meiner Meinung nach sollte es bezüglich S.M.A.R.T. egal sein, ob die HDD verschlüsselt ist oder nicht. Dementsprechend würde ich die Platte verschlüsseln und gut ist's. Ist bei mobilen Geräten meiner Meinung nach um einiges wichtiger als bei stationären, aber eingebrochen wird ja auch. Ich hab da mal einen recht ausführlichen SuperUser-Post gefunden, der da bissl näher drauf eingeht: https://superuser.com/a/1158788

    Hi, ja, auf S.MA.R.T. hat es natürlich keinerlei Auswirkung, das ist klar. Evtl. hatte ich es missverständlich formuliert (da ging es nur um eine Platte die defekt ist - und bei der Gelegenheit habe ich mich gefragt wie es mit Verschlüsselung wäre d.h. besser oder schlechter).
    Allerdings hatte ich mir auch beim Schreiben meiner Frage es im Prinzip schon selbst beantwortet. Da full disk encryption ja aus Sicht des OS transparent ist - d.h. auch das Filesystem kommt erst "danach" - dürfte man also nicht schlechter dastehen, wie ohne Verschlüsselung - was zB retten/reparieren eines defekten Filesystems, Kopieren noch lesbarer Daten von defekter HDD etc angeht.


    Die Grundsatzfrage, ob es nicht evtl. mehr Sinn macht, die Dateien selbst zu verschlüsseln, bleibt natürlich. Zumindest für mich. Zumal sicher vor Diebstahl etc ok - aber Trojaner auf dem PC der deine Urlaubsbilder, Steuererklärung etc hochläd - auch uncool. Muss ich mal darüber nachdenken...

    Hey, tote sollte man ja eigentlich ruhen lassen ... aber vielleicht ist doch die Langzeiterfahrung interessant? (zumal ich jetzt* in eine intensivere/erweiterte Nutzung gehen will)
    Also - das System hat ja doch nun schon einige Jahre auf dem Buckel ... aber läuft noch wie am ersten Tag. Sogar die Lüfter wurden bisher nicht ersetzt. Lediglich 2x NVMe SSDs aufgerüstet und SATA-SSD dadurch ersetzt.
    Aber halt: eine Sache doch: Mit den WD Red habe ich persönlich nicht wirklich gute Erfahrungen gemacht, von den ursprünglich - ich meine 5 angeschafften, haben/hatten 2 mittlerweile Defekte - wobei das sicher nicht an übermäßiger Beanspruchung lag - vielleicht sind sie auch an Langeweile gestorben.
    *) jetzt - die wichtigste Lehre aus dem Ganzen: Oversized :-) ok, klingt hart und vielleicht stimmt es ja nicht 100% - zwischendurch war ich ja schon auch mal ganz froh für schnelle Tests genug Leistung/Platz zu haben ... aber: Aktuell dümpelt das System bei rund 4-5% CPU und 12-13 GB RAM rum ... zB 64 GB im System waren jetzt nicht so die nachhaltige Wertanlage - finanziell betrachtet ;-)
    Es ist natürlich auch etwas meiner initialen Anforderung geschuldet eher ein Server als ein NAS - Eines für Alles + evtl. noch kommende Anforderungen zu bauen - das hat auch geklappt - s.o. - aber eben auch seinen Preis - im wahrsten Sinne des Wortes.
    Also - wieder bewahrheitet es sich: je besser / enger man die eigenen *momentanen* Anforderungen kennt und *diese* abdeckt desto besser. Zu weit in die Zukunft planen loht nicht.
    Dennoch - gutes System. Und vielleicht wenn man die Komponenten auf dem Gebrauchtmarkt bezieht - ein Schnäppchen (zumindest habe ich einen relativ neuen Artikel gefunden, in dem ein ähnliches aber etwas langsameres System verwendet wird)

    Hi,


    die Frage mag doof klingen - "natürlich" sollte man unbedingt die NAS-Platten verschlüsseln ... aber ist das wirklich so?


    - Performance: ok, wäre jetzt vielleicht nicht Prio. In einem flüchtigen Test kam ich mit 1 große Datei auf eine NAS-HDD via 1 Netzwerkkarte (GBit) lesen/schreiben auf jeweils > 100 MB/s - sowohl verschlüsselt als auch unverschlüsselt. Unverschlüsselt waren es vielleicht ein Tick mehr - sagen wir 108-115 statt 102 oder so - aber egal oder Meßungenauigkeit - außerdem ist mein Laptop auch nicht optimal, um die max. Geschwindigkeit auszureizen)


    - Sicherheit im Sinne Datensicherheit/Verfügbakeit:
    Ausgelöst durch meine ganz aktuelle Erfahrun: Wollte einige WDRed in Betrieb nehmen, die bisher darauf harrten, zum Einsatz zu kommen. O.g. Test gemacht (unerschlüsselt) - schreiben alles ok. Dann Datei wieder lesen - komische Einbrüche, am Ende E/A Fehler. Nachgelesen ... vermutl. Platte defekt. Test gemacht - tatsächlich: defekte Sektoren (und S.M.A.R.T. zeigte da auch schon defekte Sensoren an - leider aber etwas "zu spät", wenn es reale/wichtige Daten gewesen wären).
    Nun habe ich mich gefragt: ok - bei unverschlüsselt schon doof, wenn einige Dateien schrott sind. Wie wäre es aber bei einer verschlüsselten HDD? Macht das einen gravierenden Unterschied? Außer die defekten Sektoren betreffen den Header.
    Bei Container-Verschlüsselung zB steigt das Risiko m.E. beträchtlich, weil es da viele Faktoren gibt, die einen Container unbenutzbar machen.


    Die alternative wäre ja, wirklich schützenswerte Daten filebasiert zu verschlüsseln (autom. über einen entsprechenden Client).


    Erfahrungen? Meinungen?

    hm ... dann hab ich es wohl zufällig richtig gemacht. D.h. Alle Platten, aber dann Freigabe "Daten" angelegt (Ordner wurde entsprechend angelegt/vorgeschlagen).


    Ach ja - gibt es einen Richtwert für die Parity je HDD - hab da im Moment glaube ich noch die Default 8 GB - ist wohl zu wenig (4TB Platten). (jetzt wo ich 4 TB lese kommen die mir so klein vor ...).


    Sc0rp: welche Policy verwendest du denn? Evtl ist es ja für die Platten schonender, wenn man die lieber nacheinander füllt (weil dann die Sachen bei einem Zugriff beisammen liegen und nicht 2+ HDDs anlaufen müssen?)

    mergerfs nicht direkt im root der Festplatte, sondern in einen Unterordner deshalb:

    • snapraid schreibt im root directory jeder Platte eine Datei (die solltest du nicht sehen im Pool)
    • mit mergerfs merkst du eh nicht, dass alles in einem Subdirectory liegt, sondern siehst nur das Pool
    • du kannst auf einer Platte mehrere mergerfs Pools anlegen

    die Ordner würde ich alle gleich nennen, am besten wie den Pool dann.


    ich synchoniziere SnapRAID händisch, nachdem ich neue Mediendateien auf mein Pool gespielt habe.
    immer beachten: mergerfs => pool, snapraid => Datensicherheit, und dann gibt es noch das Backup...

    und wie (das mit den Ordnern)? Mergerfs zeigt mir bei "add file system" nur Festplatten an, keine Ordner.
    Was wäre ggf. der Anwendungsfall für mehrere Pools?


    Wie verteilst du denn die Dateien auf die HDDs? Eine nach der anderen füllen, alle gleichmässig, ...?

    Hi zusammen,


    ich wollte mir mal mergerfs + snapraid näher ansehen. Dazu sind mir einige grundlegende Fragen gekommen, auf die ich hier so nicht direkt die Antworten gefunden hatte:


    - welches ist die "beste" Policy für das Speichern von Dateien (meister/wenigster Speicherplatz, exist. Pfad, etc.) bzw was sind die Vor/Nachteile? Meine ich hätte wo etwas gelesen, dass es auch Auswirkungen auf die Synchronisation hat. Ein anderer Gedanke war, evtl. das Risiko zu streuen, wenn nicht alles auf einer HDD liegt (wobei das ja die Parity auch sicherstellen sollte). Evtl. Geschwindigkeit lesen/schreiben von mehreren HDDs vs. laufen ggf. auch mehere HDDs statt nur eine.


    - ihr scheibt ja, dass man entgegen der Anleitung nicht direkt das root einbinden soll, sondern einen Ordner anlegen. a) was genau ist der Grund und b) kann Jemand die Schritte genauer beschreiben? (zB sollen/müssen die obersten Ordner dann je HDD gleich lauten oder dürfen sie genau das nicht)?


    - wie macht ihr es mit der Synchronisation? Autom, von Hand, chronjob o.ä.?

    Code
    root@nas01:~# apt-get install iscsitarget-dkms
    Paketlisten werden gelesen... Fertig
    Abhängigkeitsbaum wird aufgebaut.
    Statusinformationen werden eingelesen.... Fertig
    iscsitarget-dkms ist schon die neueste Version.
    0 aktualisiert, 0 neu installiert, 0 zu entfernen und 18 nicht aktualisiert.


    was meinst du genau "bei VMware"? Also RDP ja in den Gast rein (sofern der das kann). Ansonsten kann man per VMware-(Web-)Client auch direkt auf die Konsole (sprich: "den Bildschirm") der Gäste zugreifen.
    TV hab ich nur, wenn es sein muss. Scheint mir oft langsamer als RDP.