Beiträge von Qser

    Das Problem scheint bei mir nicht aufzutreten.


    Egal ob ich nur den LXC-Container neu starte oder das komplette NAS reboote:

    Pi-Hole kommt nach kurzer Zeit hoch und erledigt seine Aufgabe.

    Da die Daten auf einem fremden Server liegen, würde ich bei sensitiven Daten auf jeden Fall eine Client-Verschlüsselung empfehlen.

    Die Daten die ich auf dem Remote-Server ablege sind tatsächlich clientseitig verschlüsselt. Sogar bevor sie auf das NAS gelangen.

    Allerdings werde ich nicht alles was ich bei Hetzner hochlade verschlüsseln, z.B. wenn es nicht personenbezogen ist.


    Danke für den Tipp mit dem lokalen FTP-Server. Gute Idee das damit zu testen.


    Danke auch für die Auskunft was das FTPS Protokoll angeht!

    Hallo QNAP-Club,


    ich habe im HBS3 einen FTP-Remote-Server eingerichtet. Mein Online-Storage-Provider Hetzner bietet als Zugriffs-Möglichkeiten FTP, WebDAV, Samba/CIFS-Share.


    Der Einfachheit halber, weil das standardmäßig bei Hetzner ohnehin immer aktiviert ist wollte ich im ersten Schritt FTP als Sicherungsprotokoll benutzen.

    • Habe das im HBS3 auch eingerichtet bekommen und das Backup funktioniert.


    Bin allerdings etwas verunsichert, wegen der "spartanischen" HBS-GUI bei der Konfiguration des Remote-Ziels.

    • Werden die Zugangsdaten verschlüsselt übertragen?
    • Den Haken bei FTP mit SSL/TLS (explizit) habe ich gesetzt. (siehe Screenshot anbei)
    • Was wird denn jetzt für die Übertragung benutzt? FTP oder sFTP?
    • Impliziert SSL/TSL das sFTP benutzt wird?

    Bildschirmfoto 2020-02-22 um 12.53.05.png


    Würde mich freuen, wenn da jemand was dazu sagen könnte.

    Hallo Forums-Mitglieder,


    ich habe auf meinem TBS-453A ein verschlüsseltes Volume.

    Da das NAS nicht ständig durchläuft finde ich es mühsam das Volume nach jedem Neustart manuell über die Web-Gui zu entsperren.


    Den Schlüssel würde ich eher ungern auf der NAS selbst hinterlegen.


    Ist es möglich das Volume über eine SSH-Verbindung zu entsperren? Kennt sich da jemand damit aus?

    Über Hilfe wäre ich echt froh.


    Das Problem sind jetzt eher nicht die Befehle für cryptsetup, sondern wie man die Sache so angeht, dass auch die Zugriffe per Speichermanager und Filestation noch funktionieren.


    Wobei auch cryptsetup lustig ist ... es möchte das Passwort nicht im Klartext haben. Das verstehe ich auch nicht so ganz.


    Das hier habe ich dazu bereits gefunden. Der einzige Artikel hier im Forum nimmt auch die Befehle aus diesem Link.

    https://helpdesk.qnap.com/inde…em-entsperren-und-mounten


    Allerdings hatte ich dann im Speichermanager beim entsprechenden Volume ein rotes Kreuz und den Hinweis "entsperrt".


    Über die Konsole konnte ich auf den Mountpoint zugreifen.

    Ja, es ist tatsächlich genau so. Auf der 1TB SSD liegen das System und die meisten Apps.

    - Im Erweiterungsgehäuse habe ich gerade ein Raid1 als Single Static Volume (2 x 4TB). Davon gibt es ein externes Backup.

    - Außerdem ist da noch eine 2TB-Festplatte mit Volume-Verschlüsselung drin. Auch davon gibt es ein Backup.


    Nach einiger Recherche (auch hier im Forum= sieht es so aus, als könnte man den das System auf der 1TB-SSD wohl nicht 1:1 auf ein RAID1 aus den beiden 500MB-SSDs umziehen.

    - aus Gründen der Hochverfügbarkeit wäre es mir so lieber ...

    Hallo Qnapclub-Community,


    bin neu hier, und nach einigem Lesen ziemlich fasziniert von dem Know-How das hier vorhanden ist.

    Bin vor einer Zeit auf ein neues NAS umgestiegen. Hatte das Model TS-219, das mir nach 6 Jahren wirklich zu klein geworden ist (RAID1 mit 1,5TB-Platten).

    Bin jetzt bei einem TBS-453A gelandet, in Kombination mit einem UX-500P-Erweiterungsgehäuse (momentan RAID1 mit 4TB-Platten).

    Das NAS mit dem Erweiterungsgehäuse soll einerseits auf Jahre hin genügend Speicherplatz zur Verfügung stellen können, andererseits mehrere Virtuelle Maschinen zur Verfügung stellen (Webserver, Cloud-Server, ...).


    Mein Problem ist, dass ich beim Aufsetzen des Betriebsystems leider von Tuten und Blasen keine Ahnung hatte. Ich gebe es zu. ;)
    Ich habe letztlich herumexperimentiert.


    Mein aktueller Stand ist, dass ich das NAS gerne neu aufsetzen möchte, ohne die Daten auf dem Erweiterungsgehäuse "zu verlieren".

    • Wenn es geht möchte ich das Erweiterungsgehäuse einfach an das zurückgesetzte NAS anschließen, und mit den Daten auf dem UX so weiterarbeiten als wäre nichts gewesen.


    Der Wunsch nach einem Zurücksetzen des NAS besteht, da ich mit der Aufteilung der internen SSDs unglücklich bin. Da die so teuer sind, möchte ich da keinen Speicherplatz vergeuden.
    Momentan habe ich eine 1TB-SSD im Gerät, die ich gerne wieder ausbauen möchte, und gegen 2 x 500GB im Raid1 ersetzen.

    • von dem her denke ich, dass ich das NAS neu aufsetzen muss, oder?

    1000 x Danke für das posten der Lösung. Es ist einfach genial, dass Du es hier noch geteilt hast!

    • Bin fast verzweifelt, weil ich ein einzelnes AFP-Share nicht mehr mounten konnte.
    • Außerdem habe ich den Fehler zuerst an einer anderen Stelle vermutet, da es sich um ein LUKS-verschlüsseltes Volume handelt!
    • Da sich das Share aber per SMB mounten ließ habe ich nicht aufgegeben, und bin so auf Deine Lösung gestoßen.


    Letztlich hat es bei mir dann das löschen der .AppleDB folgendermaßen funktioniert, und das Share konnte wieder gemountet werden.


    Folgende Terminalbefehle:

    ssh -l <benutzer> 192.168.x.x (Benutzername und IP anpassen)

    cd /share/<freigabe> (Freigabename anpassen)

    ls -a

    rm -R .AppleDB/


    Hm, ich habe an meinem TBS-453A ein Erweiterungsgehäuse UX500P.
    Mit einem RAID1 von zwei 4TB Festplatten hatte ich eine Lesegeschwindigkeit von 110MB/s und Schreibgeschwindigkeiten von ca. 100MB/s im Gigabit-LAN.


    Jetzt habe ich eine dritte 4TB Festplatte eingebaut, und in ca. 30 Stunden auf RAID5 migriert. Ich hatte erwartet, dass die Performance etwas nachgibt ... aber während die Leseperfomance weiterhin 110MB/s beträgt, lassen sich die Freigaben nur noch mit ca 28-30MB/s befüllen.


    Das schmerzt schon, da ich schon mit größeren Datenmengen hantiere.
    Gibt es evtl. Tipps ?


    n1ck schrieb im vorherigen Thread, dass ein erneuter Aufnau des Raids das Problem gelöst hat. Bevor ich den Aufwand betreibe ... meint ihr, dass da Aussicht auf Besserung besteht?