Beiträge von Anthracite

    Wie geht das? DIR kennt es nicht.

    ls -l ist dein Freund.


    Eine Liste der wichtigsten Befehle gib t es hier bei Ionos (wobei die Liste schon etwas lang ist; da sind auch einige Befehle dabei, die ich noch nie benutzt oder gebraucht habe).

    Hat es denn keine fertigen Lösungen für Allerweltsaufgaben wie regelmäßige Datensicherung?

    In dem Falle handelt es sich um einen Backupmechanismus eines Drittproduktes. Die MariaDB-App müsste dieses Backup in ihr GUI integrieren.


    Aber dein erstes Problem ist, dass der MariaDB-Daemon scheinbar nicht läuft.


    Hast du mysqld start mit vorangestelltem sudo probiert? Was ist das Ergebnis?

    Ich würde mal auf den virtuellen Switch "Container Network" als Übeltäter tippen. Die Konfiguration des Switches sieht mir auch nicht gesund aus. MMn. müsste der auch am Adapter 1 hängen.


    Ich hatte einmal einen Absturz in der Linux-Station (die auf der Container-Station basiert), wo auch komplettes Löschen von Linux- und Containerstation und Neuinstallation der beiden Apps nicht weitergeholfen hat. Auch habe ich es im GUI nicht geschafft, die zerbröselte Konfiguration zu kitten.


    Geholfen hat letztlich, den virtuellen Switch komplett zu löschen, Linux- und Containerstation zu entfernen und neu zu installieren. Bei der erneuten Installation wurde der virtuelle Switch wieder angelegt, und diesmal mit einer funktionierenden Konfiguration. Danach lief alles.


    Das könnte auch bei dir die Lösung sein. Garantie dafür gebe ich aber nicht.


    (Und kurz darauf habe ich die Linux-Station endgültig gelöscht, weil sie nicht meinen Ansprüchen genügt hat. Aber das ist eine andere Geschichte.)

    /usr/local/mysql/bin/mysqldump -u [Name eines Nutzers der DB mit allen Rechten] -[Passwort dieses Nutzers] [Name der zu sichernden Datenbank] >dump.sql führt mich zu

    Der Dump sollte nicht mit irgendeinem Benutzer erstellt werden, sondern immer mit root, da andere Benutzer üblicherweise nicht auf alle Datenbankobjekte zugreifen dürfen, und dann fällt der Dump auf die Nase. Aber nicht das ist die Ursache für deine Fehlermeldung, sondern dass der Datenbank-Daemon nicht läuft.


    root hat übrigens eine Besonderheit gegenüber anderen DB-Zugängen: Die Anmeldung kann idR. nur lokal erfolgen. Wenn du dich mit ssh am NAS angemeldet hast und greifst da auf die DB zu, dann ist das der Fall, nicht aber, wenn du auf dem PC ein Programm startest, das auf die DB zugreift.

    /mnt/ext/opt/mariadb/bin/mysqld start endet in

    Setz mal ein sudo davor, damit admin der User ist, der die DB startet. Das könnte deine nachfolgende Fehlermeldung erklären. Dein normaler User hat möglicherweise keinen Zugriff auf irgendwelche MariaDB-Verzeichnisse oder Dateien.


    Wenn nicht, schau mal, ob es das Verzeichnis

    Code
    Can't change dir to '/mnt/ext/opt/mariadb/data/' (Errcode: 2)

    überhaupt gibt. (Ich habe MariaDB nicht als Qnap-Package installiert, sondern in einer VM, und da mögen die Pfade anders sein.)

    Aber ist es nicht so, daß der Datenbankserver laufen muss, wenn die App auf dem NAS läuft?

    Im Prinzip schon, nicht aber, wenn der Start des Daemons aus irgendwelchen Gründen scheitert. App stoppen (nicht deinstallieren!) und wieder starten kann auch dazu führen, dass der MariaDB-Daemon wieder läuft.

    Wenn sich der Keller nicht 5 Etagen tiefer befinden würde, wäre das auch meine Option gewesen

    Und lass mich raten, es ist nicht daran gescheitert, weil du zu faul zum runtertragen wärest ;)


    In vielen Häusern gibt es Kabelschächte, in die dann auch noch ein LWL-Kabel passt. Manchmal kann auch ein Kabel von Kabelfernsehen dafür zweckentwendet werden. Aber in Mietwohnungen macht man dann den Aufwand doch nicht.

    Dann kannste die Dateien ja von Usprungsort wiederherstellen, wenn nicht, dann jst das NAS KEIN Backup.

    Im Prinzip richtig, aber dabei geht die Backuphistorie verloren, und die hätte man eigentlich schon ganz gerne. Gut, jetzt könntest du sagen, dann muss man für die Historie ein Backup vom Backup machen, aber es ist durchaus ein Kompromiss, darauf zu verzichten, und im Ernstfall verliert man halt die Historie.

    Wenn das RAID 1 mit den beiden SSDs der limitierende Faktor sein sollte,

    Zwei SSDs im Raid 1 können lesend 10GbE ausnutzen, schreibend hingegen nicht. Es kann aber andere Bremsen geben, z. B. Prozessorleistung, Dateigröße oder manchmal auch die Messmethode.

    Selbst wenn der Qnap QNA-T310G1T Adapter nur "summen" sollte wäre das für mich am lüfterlosen MacBook Air irgendwie uncool.

    Das sehe ich übrigens auch so. Es war eine sehr gute Aktion hier, das NAS in den Keller zu verbannen.

    Ich werde berichten wo die Reise hingeht

    Ja, mach mal.

    Das muss nicht am NAS liegen, denn in anderen Anwendungen funktioniert nfs genauso wie bisher auch.


    Dein Shield 2017 basiert auf Kodi. Ich würde daher mal suchen nach Problemen, die es unter Kodi mit nfs gibt.


    Es könnte auch an Einstellungen für nfs auf dem NAS liegen. Zwischen nfs 3 und nfs 4 gibt es große Unterschiede. Versuch es mal, am NAS nur Version 3 und mal nur Version 4 einzuschalten, ob dir das weiterhilft.


    Leider kann ich dir keine konkreteren Tipps geben, da ich das Shield 2017 nicht habe.

    iscsi benötigt ein eigenes Volume. Wenn in dem Speicherpool kein Platz mehr vorhanden ist, muss ein bestehendes Volume verkleinert werden. Beim Verkleinern besteht potentiell das Risiko eines Datenverlustes (z. B. durch Stromausfall im falschen Moment). Daher ein Backup der Daten vor dem Verkleinern machen.


    iscsi synchronisiert nicht zwischen den Zugriffen durch verschiedene Rechner. Wenn von zwei verschiedenen Rechnern gleichzeitig auf das gleiche iscsi zugegriffen wird, kann es Datenverluste geben.


    Wenn iscsi einmal eingerichtet ist und dann nur du darauf zugreifst, gibt es kein besonderes Risiko von Datenverlusten (außer denen, die immer bestehen wie Schadprogrammen oder Fehlbedienungen, aber das betrifft Freigaben genauso).

    -ppassword

    Da steht jetzt sicher nicht 'password', sondern dein richtiges Passwort?


    Die Fehlermeldung tritt aber üblicherweise auf, wenn der MySQL- oder MariaDB-Server (=Daemon) nicht gestartet ist. Siehe z. B. hier.


    Die Meldung bedeutet, dass der Befehl mit Super-User-ID ausgeführt werden muss - also mit dem root-Account (admin).

    Ein sudo vor dem Befehl tut's auch und ist das Gleiche. (Dr Mike weiß das sicherlich; das ist eine Info für BillBeaver.)

    Und es geht um RJ45

    Tja, Pech gehabt ...


    Nimm einfach einen der von dir erwähnten Adapter von OWC oder Sonnet. Lt. Hersteller sind die tatsächlich lüfterlos. Die Geräuschlosigkeit ist den Aufpreis wert, und eine Umstellung auf sfp+ und Glasfaser/DAC wäre deutlich teurer. Da ich die beiden Adapter nicht kenne, kann ich keine weiteren Aussagen dazu machen, aber entweder er funktioniert oder er funktioniert nicht, das hast du schnell raus.


    Glasfaser also SFP nehmen da Lüfterlos!

    Du meinst sicherlich sfp+.


    sfp ohne Plus gibt es auch. Der Unterschied ist, dass sfp nur Gigabit kann. Heute ist sfp ohne Plus deswegen nicht mehr aktuell, aber gerade, wenn man gebraucht kauft, muss man aufpassen, nicht das ältere sfp zu erwischen. sfp und sfp+ haben denselben Schacht und sind begrenzt kompatibel zueinander, manche Kombinationen funktionieren, andere nicht, aber sobald irgendwo sfp ohne Plus im Einsatz ist, ist die Geschwindigkeit auf Gigabit begrenzt.

    Meine Empfehlung:

    QNA-T310G1S

    - ein sfp+ Port

    - bei Kauf (war 2020) mit Abstand der billigste Thunderbolt3-10GbE-Adapter

    - relativ klein

    - an der Leistung gibt es nichts auszusetzen

    - lüfterlos und damit vollkommen lautlos


    Hinweis: Der Qnap QNA-T310G1T mit rj45-Port für 10GbE über herkömmliches Kupfer ist nicht lüfterlos und somit nicht lautlos. Wie störend das Geräusch ist, weiß ich nicht, da ich ihn nicht kenne.


    Und da ich annehme, dass Qnap den Lüfter nicht in die rj45-Variante einbaut, um die Kunden zu ärgern, sondern es einen Sinn haben wird, denke ich, dass es keine gute Idee sein wird, den sfp+ Adapter dauerhaft mit einem rj45-Transceiver, der relativ viel Strom verbraucht, zu nutzen. Transceiver für LWL und DAC-Kabel sind sparsamer. Mit LWL-Transceiver wird der Adapter angenehm handwarm, aber nicht so heiß, dass man sich um Adapter oder Umgebung Sorgen machen müsste. Der Switch auf der Gegenseite braucht dann natürlich auch einen sfp+ Port.


    Unterhalb von 200€ gibt es da gefühlt nichts - und die Lösung von Qnap soll zudem auch relativ viel "Krach" machen was uns stören würde.

    Das mit Qnap und Krach stimmt für den genannten sfp+ Adapter definitiv nicht. Der ist absolut lautlos.


    Was den Preis angeht - nun, ich habe meinen Adapter vor drei Jahren gekauft und seitdem den Markt nicht mehr beobachtet. Ich habe aber das Gefühl, dass sich da nicht viel getan hat.

    Die Platte 2 steht auf deiner Bildschirmkopie im Status "Suche nach fe...". Falls immer noch so, geh mal mit der Maus rüber, was das komplett heißt.


    Falls die Platte mittlerweile im Status "bereit" angekommen sein sollte: Macht jetzt das Raid ein Rebuilt?


    Und bitte Geduld. Ein Rebuilt kann durchaus 24 Stunden dauern.


    Möglicherweise kann man das Raid auf Shell-Ebene mit Linux-Befehlen (z. B. mdadm) auch dann wieder aktivieren, wenn es über die Web-Oberfläche oder automatisch nicht mehr geht. Da man hier aber auch viel zerschießen und endgültig zerstören kann, würde ich das nur angehen zusammen mit dem Qnap-Support.

    ist das normal, dass sich so ein Teil im Dauerbetrieb irgendwann auflöst?

    In der Form? Nein.

    Im Forum habe ich noch nicht davon gelesen, das ein NAS Stecker zum Schmelzen gebracht hätte. Klar, Defekte aller Art gibt es, aber meistens ist das Gerät einfach tot.


    droht entweder die Sicherung (kommt die dann irgendwann?) oder ein Feuer

    Meistens knallt irgendwann die Sicherung durch. Die Erhitzung kann zur Folge haben, dass der Strom besser fließt, so dass schnell die Stromstärke erreicht wird, bei der eine Sicherung reagiert.


    Oder nach einigen Minuten ist weggekokelt, was kokelt kann, und der Strom fließt deswegen nicht weiter.


    Ein sehr geringes Restrisiko bleibt aber, dass es längere Zeit kokelt, ohne dass die maximale Stromstärke überschritten wird. Das liest man manchmal nach Bränden in der Zeitung, Ursache war ein defektes Küchengerät o. Ä.. Entfernte Bekannte hatten mal einen Brand in der Wohnung, weil ein Deckenstrahler defekt war - die Bude ist nicht mit abgefackelt, aber der finanzielle Schaden durch den Rauch in der ganzen Wohnung war erheblich. Helfen kann, das NAS (oder sonstiges Gerät) so aufzustellen, dass keine brennbaren Materialien in der Nähe oder darüber sind.

    Tja, was soll ich sagen...damit bekommt der Docker eine Ressource auf der Festplatte...

    Das ist dann die richtige Lösung. Dann läuft die Ramdisk auch nicht voll, selbst wenn ein Programm im Docker mehrere Gigabyte Plattenspeicher nutzt.


    Die Vergrößerung der Ramdisk in autorun.sh ist dann vermutlich nicht mehr nötig. Du kannst es ja mal beobachten, die Vergrößerung erst einmal drin lassen und gegebenenfalls später rausnehmen. Wobei, so viel RAM, wie du hast, ist das eigentlich auch egal.

    könnte ich die Autorun.sh so schreiben?

    Nein.


    Du müsstest das in etwa so machen:

    Code
    cp -Rp /unifi/* /share/Container/unifi/
    rm -rf /unifi 2>/dev/null
    ln -s /share/Container/unifi /unifi

    Bitte unbedingt aufpassen mit rm -rf. Wenn dir zwischen / und unifi versehentlich ein Leerzeichen gerät, crashst du das ganze System. (Hast du eigentlich ein Backup?)


    Die Befehle kannst du einmal ausprobieren , bevor du sie in autorun.sh einbaust. Ich habe sie bei mir nicht getestet. Zum Ausprobieren wird eventuell ein sudo davor benötigt.


    Der cp-Befehl ist überflüssig, wenn Unifi zu dem Zeitpunkt noch nicht läuft oder noch nichts in das Verzeichnis geschrieben hat.


    Und dann noch was: Entweder Ramdisk vergrößern oder Link anlegen, aber nicht beides.


    Die beste Möglichkeit ist aber mMn., stattdessen die Konfiguration von unifi zu ändern (mein erster Vorschlag im vorangegangenen Beitrag).