mgutt

Ich habe das gerade mal ausprobiert und mit der Lösung aus dem Link geht es. Allerdings erhalte ich den Fehler, dass ich angeblich das falsche Passwort eingebe: Ich dachte ADMIN_TOKEN ist das Passwort?!

Der Punkt ist, dass schon deine Frage der Grund ist, warum ich das ungern machen würde. Ich sag ja, dass man das erst machen sollte, wenn man die Pfade verstanden hat. Deine Aufgaben: 1.) Was ist der Unterschied zwischen /mnt/cache/sharename und /mnt/disk1/sharename und /mnt/user/sharename? 2.) Wo kann man in der unRAID GUI sehen welche Dateien in den drei verschiedenen Pfaden liegen? Dann hast du die Antwort auf deine Frage. Um dich nicht im Regen stehen zu lassen: Die Vorgehensweise ist richtig und man muss nichts verschieben, sofern wirklich alles auf dem Cache liegt, denn Cache Pool = /mnt/cache Und prüfen kann man das über die Share Ansicht > Location.

Meinst du wegen der Fehlermeldung? Ich denke mal du musst sowas machen wie ich: https://forums.unraid.net/topic/115369-nginx-ssl-zertifikat-für-lokal-genutzte-domains/?tab=comments#comment-1048918 Damit kann ich alles über https erreichen, aber eben nur lokal. Wobei man um die Portfreigabe nicht herum kommt, wenn man keine DNS Challenge machen kann (weil Let's Encrypt ja über Port 80 dann die URL Challenge macht). Also entweder hast du eine eigene Domain und machst eine DNS Challenge und lässt alle Ports zu oder du nimmst eine DDNS und öffnest Port 80 (ginge im Härtefall auch nur alle 3 Monate für den Refresh der Let's Encrypt Validierung). Oder vielleicht ein Cloudflare Zertifikat? Das ist ja meine ich auch kostenlos. Ich habe dann über die erweiterten Einstellungen des Containers bei WebUI meine Domain https://passwords.example.com hinterlegt. Auf die Art geht die dann direkt über die verschlüsselte Domain auf. Alternativ müsste man es mit einem self-signed Zertikat versuchen, das man in seinem Browser installiert. Aber ohne Proxy (NPM oder SWAG) davor geht es denke ich nicht, da der Container selbst ja nur auf Port 80, also http lauscht.

@Roxedus Could you please add more explanation to the different container variables to the container description? Things like the ADMIN_TOKEN are not explained (even not here in the first post).

Er nutzt Vdisks auf einer UD und schleift nicht die komplette NVMe an eine VM durch.

Das wird so oder so passieren, denn du greifst ja sowohl auf alte (Array) als auch neue Dateien (Cache) über die Nextcloud zu. Die einzige Lösung wäre eine ausreichend große SSD wo die komplette Nextcloud drauf passt und den Share dann auf Prefer.

War der Browser evtl noch offen? Da passieren manchmal so komische Sachen.

Nutzt du Cache Only bei einem vorgelagerten SSD Cache und der läuft voll, schmieren dir die Container ab, weil sie keine Daten mehr schreiben können. Diesen Nachteil hat man nicht, wenn man Prefer nutzt, die Container Pfade auf /mnt/cache ändert und einen Min Free Space beim Cache Pool einstellt. Denn dann läuft die SSD niemals voll, die Container haben noch genug Platz zum Schreiben und /mnt/cache umgeht Fuse und entlastet damit massiv die CPU. Aber das (und auch Cache Only) empfehle ich nur Fortgeschrittenen, die Backups haben und die verschiedenen unRAID Pfade verstanden haben.

Dann kannst du unRAID komplett offline nehmen. unRAID benötigt keine Internetverbindung. Erst wenn du Apps installieren möchtest, brauchst du (zeitweise) eine Verbindung. Die Quellen dafür sind aber unterschiedlich. Das kann zB GitHub oder Docker Hub sein. Welche genau müsstest du selbst per Reverse Engineering herausfinden. Ich kenne jedenfalls keine Liste. Am einfachsten wäre wohl einen eigenen DNS zu betreiben, der die Anfragen loggt.

Der Sharename fängt mit "P" an? Laut Logs darf der als einziges alle Disks nutzen. Appdata und System sind bei dir übrigens auf Cache und Disk. Du solltest den Docker Dienst deaktivieren und den Mover starten, damit alles auf den Cache verschoben wird. Das darf niemals passieren. Es haben sich also Daten geändert, die auf der Parität nicht angekommen sind. Also gekippte Bits, was durch die Logs bei md4 = disk4 ja bestätigt wird. Das muss nicht zwangsläufig durch die Disk kommen (da sehe ich jetzt auch keine gravierenden Fehler), sondern kann auch durch defekten RAM resultieren. Hast du ECC RAM? Eine Reparatur wäre im Maintenance Mode möglich. Dabei werden aber keine kaputten Dateien repariert (kann XFS nicht), sondern nur die Metadaten angepasst. Vom Prinzip kann man dem Inhalt von Disk 4 also nicht mehr trauen und sollte diesen aus einem Backup wiederherstellen. Frag mich nicht aus man die defekten Dateien ermittelt. Keine Ahnung. Aber mach erstmal die Reparatur. Mal sehen was dabei herauskommt.

Ich würde eine Kombi aus lokalem Mailserver und Thunderbird Docker vorschlagen. Der lokale Mailserver wird dann ganz primitiv über eine DDNS betrieben. Also sagen wir mal [email protected] Nun nutzt man den Thunderbird Docker, hinterlegt beide Mailkonten und erstellt für jeden Ordner Regeln, der zB die Mails aus "Gesendet" von [email protected] in "Gesendet" von max_archiv verschiebt. Allerdings macht man das nicht für den Posteingang von max. Da lässt man die Mails drin. Auf allen Geräten hinterlegt man ebenfalls beide Mailkonten, hat aber beim Erstellen neuer Mails max als Standard eingestellt. Man öffnet also ganz normal den Posteingang von max und liest seine Mails und sobald man antwortet oder löscht, verschiebt der Thunderbird Docker alles nach max_archiv. Damit versehentlich keine Mails über max_archiv versendet werden, zB weil man in den dortigen Papierkorb wechselt und darüber auf eine Mail antwortet und vergisst das Absender-Dropdown zu ändern, sollte man nach der erfolgreichen Einrichtung der Endgeräte, die Ports 465 und 587 von max_archiv sperren. Oder vielleicht findet man auch einen anderen Trick wie zB dass der max_archiv Mailserver einen durchgehend vollen Postausgang besitzt und neue Mails dann mit "Postfach voll" ablehnt oder so. Spamfilter für max_archiv braucht man dann nicht, weil ja niemand die Adresse kennt.

Update auf unRAID 6.10 und dort bei den Docker Einstellungen auf IPVLAN ändern. Das soll es wohl beheben.

@ich777 Wie war das noch mal mit dieser Shell Datei, die manche Docker beim Starten laden? Dann könnte man ja mit grep und sed prüfen und bei Bedarf die htacess korrigieren.

You first disk is an SSD and it seems a really cheap model. I think you need to install the TRIM plugin.

Dann hast du USB Laufwerke verbunden??

Macht mc evtl erst eine Kopie und verschiebt nicht einfach nur? Weil der Bug tritt nur beim Verschieben auf.

Ok, dann muss ich die Tests wohl bei 6.10 dann noch mal alle wiederholen ^^

Ja es löst einen CPU Fehler von Intel ^^ Sobald die CPU in C10 wechselt, ist das System super langsam, wenn hpet aktiv ist. Steht aber alles in dem Link. hpet=enable ist eine Kernel Option, die man in Unraid ändern kann, wenn man auf "Flash" klickt, also den USB Stick:

Die WD Black hat auf meinem C246N Board Probleme gemacht und lief nur mit deaktiviertem ASPM. Bei anderen läuft sie fehlerfrei. Und hochwertig ist die in jedem Fall. Ich habe mittlerweile die 2TB Evo Plus verbaut.

Du musst a) den syslog server auf USB schreiben lassen und b) die Zeit nennen, sonst weiß man ja gar nicht wo man suchen soll. Du kannst versuchen hpet zu deaktivieren. Siehe: https://forums.unraid.net/topic/109990-kein-spindown-nach-hardwareaustausch-mit-aktiviertem-powertop/?do=findComment&comment=1008019

Ist das lokal für einen DNS nicht unwichtig? Vergib doch einfach eine lokale IPv6. Das Problem was ich mit br0 hatte war, dass nach einem Prefix Wechsel, dieser nicht beim Container ankam, solange der lief. Du kannst ja gerne noch mal rumprobieren 😁

Und bei GitHub oder wo auch immer der Container verwaltet wird, gibt es keine Anfragen zu IPv6?

Du musst im Router natürlich für IPv4 und IPv6 den DNS, also AdGuard hinterlegen. Allerdings kann ich dir aus Erfahrung sagen, dass manche Geräte an den Einstellungen vorbei arbeiten. Ich habe zb ein Fire Tablet, wo ich als primäre und sekundäre DNS IP, die von PiHole eingetragen habe. Deaktiviere ich nun den Container, löst das Tablet alle Domains ganz normal auf. Da ist also noch ein Dritter DNS hinterlegt, den ich nicht sehen kann. Ich müsste also eigentlich jeglichen DNS Traffic bis auf den zu PiHole sperren, um das in den Griff zu bekommen.

Das passiert nicht, wenn die Platte schläft, sondern nachdem sie durch was anderes hochgefahren wurde. Das ist komisch. Also auch kein leerer Ordner (Share) drauf?

Und was machst du, wenn du einen neuen IPv6 Prefix bekommst? Dann stimmt ja die feste IPv6 vom Container nicht mehr.