mgutt

Die Platten gelten jetzt als Defekt und Unraid erwartet, dass du sie ersetzt. Du kannst nicht den Ursprungszustand wiederherstellen, da ja bereits ein Bit reicht um die die Parität zu verändern und würde man Parity 2 einfach wieder zuweisen, würden sich die beiden ja "widersprechen". Wenn du 100%-tig sicher bist, dass Disk 1 nicht defekt ist, könntest du einen Screenshot von der Übersicht machen und über Tools > New Config alle Platten neu zuordnen und die Parität neu aufbauen lassen. Oder du machst das hier und die Disk 1 wird über die Parity 1 wiederhergestellt: https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself Dann musst du aber 100%-tig sicher sein, dass Parity 1 korrekt ist (wann war der letzte Parity Check?). Wenn du Angst hast: Array stoppen und Disk 1 aushängen. Array starten. Dann Disk 1 über Unassigned Devices einhängen und ein Backup von Disk 1 erstellen, bevor du einen der oben genannten Schritte durchführst.

So it's a file based database like SQLite? Any support for external databases like MySQL?

And why isn't it possible to move them to the RAM with --mount type=tmpfs,destination=/logs or similar?

Are they writing to random folders or why isn't it possible to tweak?

Das sollte übrigens niemals möglich sein. Damit riskiert man nur, dass jemand den Server hackt. Wenn dann nur Container freigeben!

Das ist nicht die einzige Hürde. Die IPv6 ändert sich ja, sobald sich dein Anschluss neu verbindet. Das Update der Container IP ist aktuell mein Problem. Da bin ich gerade noch dran, dass ein Script die Änderung erkennt und dem Container das neue Prefix mitteilt. Denk auch dran, dass du bei 6Tunnel die DDNS Domain verwendest. Sonst musst du auch beim Tunnel ständig manuell die IPv6 aktualisieren.

IPv6 ist gar kein Problem (das ist der Nginx Proxy Manager Container auf meinem Server): http://[2003:e0:a71b:f600::8]/ Bei mir übrigens über D1 nicht erreichbar, wenn ich im Handy den APN internet.t-d1.de verwende. Aktuell verwende ich deswegen internet.v6.telekom aber wie man sowas einstellt, kannst du der Schwiegermutter nicht erklären. Deswegen auch meine Aussage, dass es nicht ohne IPv4 geht. Haben die Docker eine IPv6? Siehst du das IPv6 Netz, wenn du den Container auf br0 stellst? Beispiel: Bedenke, dass bei IPv6 kein NAT funktioniert. Du kannst also im Router keine Ports zb von 443 auf 8443 umlenken. Daher verwende ich den offiziellen Nginx Proxy Manager (stelle ich bald bei Unraid Apps rein), da der aktuelle in den Apps nicht auf 80/443 lauschen kann.

Ist es nicht. IPv6 wird gerade mal von 50% der Internetnutzer verstanden: https://www.akamai.com/de/de/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp O2 wird es zB erst diesen Monat flächendeckend einführen. Viele haben es im Netzwerk schlicht deaktiviert.

Nein, ging von der technischen Angabe bei Geizhals aus: https://geizhals.de/seagate-expansion-desktop-steb-10tb-steb10000400-a2120053.html Scheint aber eine falsche Angabe zu sein: https://www.reddit.com/r/DataHoarder/comments/h8agze/recently_shucked_steb10000400_is_that_cmrpmr/

Ist auch die Frage ob der Fernseher evtl eine Auflösung angeboten bekommt, die er gar nicht versteht?! Die verstehen in der Regel weniger Auflösungen als ein PC Monitor. Ich würde jedenfalls auch mal versuchen die iGPU nur als zweite GPU durchzuschleifen. Einfach mal um zu sehen ob LibreElec über die virtuelle GPU hochfährt. Dann kannst du auch prüfen ob die iGPU in der VM überhaupt verfügbar ist. Ansonsten würde ich mir diesen ganzen Stress gar nicht geben und stattdessen einfach eine GT710 oder GT1030 installieren. Oder du probierst es mit einer Windows 10 VM und testest das Intel GVT-G Plugin: https://forums.unraid.net/topic/108650-plugin-intel-gvt-g/ Dann noch sowas hier für die grafische Ausgabe: https://www.ebay.de/itm/164516409548

Günstig ist aktuell gar nichts (darunter verstehe ich 15 € pro TB): intern: https://geizhals.de/?cat=hde7s&asuch=&bpmin=&bpmax=&v=e&hloc=at&hloc=de&plz=&dist=&sort=r&bl1_id=30#productlist extern: https://geizhals.de/?cat=hdx&asuch=&bpmin=&bpmax=&v=e&hloc=at&hloc=de&plz=&dist=&sort=r&bl1_id=30#productlist Und zwischen den Herstellern gibt es eh keine nennenswerten Qualitätsunterschiede. Sollte nur eben keine SMR Platte sein. Also von WD jetzt keine Red, sondern Red Plus. Und bei externen Gehäusen muss man sich vorher informieren was verbaut ist zB bei Seagate sind erst ab 12TB CMR Platten verbaut.

Entweder Platte defekt oder Kabelverbindung. Was sagen die SMART Werte der Parity?

Ich nutze für Docker die Verzeichnis Variante und die SSD ist XFS formatiert. Daher habe ich eh nicht so viel TBW auf der SSD. Ehrlich gesagt habe ich es aber noch nicht ausgewertet. Ich rippe aktuell zu viel. Wenn mal eine Ruhephase ist, werte ich das mal aus.

Auf dem Weg wird das nicht klappen, weil nicht jeder deiner Nutzer IPv6 versteht und diese dann über die Domain nur auf die interne IPv4 verwiesen werden, die sie aber nicht erreichen können. Die einzige Lösung ist es deinen Provider davon zu überzeugen, dass du eine öffentliche IPv4 erhältst oder du einen VPS Server mietest, der selbst über IPv4 erreichbar ist und der dann den Traffic über einen IPv6 Tunnel zu dir nach Hause leitet. Ich bin gerade selbst an dem Thema dran und werde dazu auch noch ein Video machen. Es ist auf jeden Fall nicht leicht und viele YouTube Videos zu dem Thema sind ziemlicher Unsinn. So viel kann ich schon mal sagen. Eine öffentliche IPv4 direkt vom Provider ist nach wie vor die beste Option.

Es gibt bei jedem Container im Menü die Logs. Siehst du da Fehler? Hast du über die Kommandozeile mal einen Ping auf die IPs der Container abgesetzt? Wozu sind diese ganzen "shim-br0"? Kein Backup gemacht? Sicher? Also hast du nach dem Entfernen des Containers den entsprechenden Ordner unter appdata/ gelöscht und das App-Template unter Apps -> Previous Apps entfernt? Denn sonst startest du einfach immer wieder deine bereits existierende Installation von dem Container. Musst du natürlich wissen ob du das wirklich alles löschen und von vorne anfangen willst. Das ist eine Möglichkeit ein Problem zu lösen, die andere wäre die Ursache zu finden, damit es nicht wieder passiert.

In Unraid ist die Parität ein RAW Volume. Unraid nimmt also jeden einzelnen Sektor und erwartet, dass dieser die "Quersumme" aller Daten aller Disks darstellt. Löscht man nun eine Datei auf irgendeiner Disk und die Parität wird aktualisiert, dann ändert sich die "Quersumme" von ganz bestimmten Sektoren. Es wurde also faktisch nichts auf dem Paritätslaufwerk gelöscht, sondern nur geändert. Alle Sektoren enthalten also nach wie vor wichtige Daten, die bei einem Ausfall für die Wiederherstellung herangezogen würden. Oder anders gesagt: Bei Unraid ist die Parität immer zu 100% voll. Selbst dann, wenn das Paritätslaufwerk größer ist als alle anderen Platten. Dann schreibt zwar Unraid den Rest mit Nullen voll, aber es ist eben "voll". Bei einem BTRFS / ZFS RAID ist die Parität dagegen kein RAW-Dateiformat, sondern vom Dateisystem selbst werden auf Dateiebene Datenblöcke geschrieben und gelöscht. Und gelöschte Blöcke kann man dann auch problemlos trimmen. Aus dem Grund hat es die Firmware der SSD beim Unraid Array schwer irgendwas aufzuräumen. Denn wenn die SSD komplett voll ist, kann die Firmware nicht wirklich was machen. Und da liegt eben der Vorteil von Enterprise SSDs, die einen besonders großen Over-Provisioning Bereich bieten. Ich finde Kingston erklärt das ganz gut: https://www.kingston.com/germany/de/ssd/overprovisioning Aus dem Grund haben Enterprise SSDs auch nie 1TB, sondern 960GB Speicherplatz.

Ok sauber. Problem gelöst. Plex geht hin und testet den Zugriff von außen über die Domain https://plex.tv was mal gar keinen Sinn macht, weil diese Domain natürlich nicht auf meine öffentliche IP auflösen sollte, sondern auf die IP der Plex Website. Das heißt sie überschreiben beim Test die IP dieser Domain. Nachdem ich nämlich "plex.tv" als weitere Reverse Proxy Domain hinzugefügt habe: Zeigt Plex einen gültigen Fernzugriff an: Darauf muss man erst mal kommen.

Also die Advanced Configuration funktioniert auf jeden Fall. Ich habe eine weitere Subdomain nas.example.com mit einem CNAME auf die Hauptdomain plex.example.com erstellt und wenn ich in der Configuration diese Domain hinterlege, dann wird ebenfalls Plex geladen Dann gehe ich auch mal davon aus, dass "*.plex.direct" gehen sollte.

Leider akzeptiert NPM keine Wildcard bei der Domain, sonst könnte ich einfach alle Zugriffe von außen auf plex.direct ebenfalls durchleiten: Auch eine entsprechende Advanced Configuration hilft nicht: Wobei ich ja wie gesagt nicht mal weiß ob Plex über diese Domain prüft. Gibt es noch andere Domains, die Plex nutzen könnte? Ich weiß, dass es eigentlich egal ist, da es ja funktioniert, aber das macht mich ganz wuschig, dass der das nicht anzeigt ^^

Ok, das ist jetzt komisch. Wenn ich in NPM einen Stream Host hinzufüge und Port 443 auf 32400 weiterleite: Dann sagt Plex, dass es von außen erreichbar sei: Man muss dazu wissen, dass Stream Hosts wirklich alles auf diesem Port weiterleiten. Es wird also nicht mehr an Hand einer bestimmten Domain ein Reverse Proxy genutzt, sondern der ganze Traffic wird einfach auf den 32400 genatet. Damit werden alle Filter und auch das SSL Zertifikat ausgehebelt, weshalb das natürilch keine Option für mich ist. Ich habe natürlich auch wieder von außen getestet und ein Zugriff über https://73.77.99.34/ ist nach wie vor nicht möglich. Plex scheint also nicht über die öffentliche IP auf den Server zugreifen zu wollen, sondern ich vermute über eine eigene Domain. Kann das sein? Eventuell über etwas wie 73-77-99-34.123456.plex.direct?! Keine Ahnung wie ich das herausfinden könnte. 🤔

Ich versuche gerade Plex mit meiner eigenen Domain ausschließlich über https erreichbar zu machen. Das funktioniert auch, aber Plex behauptet steif und fest, dass es nicht von außen erreichbar sei: Kommen wir mal zum grundlegenden Aufbau. In meinem Router ist der Port 80 und 443 auf die IP 192.168.178.8 freigegeben: .8 ist in dem Fall der Nginx Proxy Manager: In NPM wird der eingehende Traffic auf https://plex.example.com an 172.19.0.2:32400 weitergeleitet: Was wiederum Plex ist: Damit der Zugriff lokal und extern funktioniert, musste ich "Eigene URLs für den Zugriff auf diesen Server" festlegen: Wenn ich nun lokal im Browser ein Video starte, dann sehe ich im Netzwerkmonitor, dass er das Video von der folgenden Domain lädt: https://192-168-178-9.123456.plex.direct:32400/ Diese Domain löst auf die lokale IP 192.168.178.9 auf: ping 192-168-178-9.123456.plex.direct Ping wird ausgeführt für 192-168-178-9.123456.plex.direct [192.168.178.9] mit 32 Bytes Daten: Antwort von 192.168.178.9: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.178.9: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.178.9: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.178.9: Bytes=32 Zeit<1ms TTL=64 Ping-Statistik für 192.168.178.9: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms Damit das überhaupt geht, musste ich den Rebind-Schutz für plex.direct aufheben: Dann habe ich bei meinem Handy einen Hotspot erstellt und das selbe mit einem Notebook wiederholt, um zu testen wie der Zugriff von außen erfolgt und da lädt er die Videos über diese Domain (er nutzt also den https Port 443): https://plex.example.com/ Also alles genauso wie ich es gerne hätte. Da der Traffic von außen ja über Port 443 reinkommt, habe ich beim Plex Fernzugriff genau diesen Port hinterlegt: Das einzige was sein könnte, dass Plex nicht über https://plex.example.com den Fernzugriff testet, sondern über https://73.77.99.34/ oder gar http://73.77.99.34:443 ?! Das wäre dann aber in meinen Augen ein Bug. Hat jemand eine Idee wie ich das prüfen könnte? Hier das Ergebnis, wenn ich von außen auf die IPs zugreife: http: https:

Damit würde Plex aber regelmäßig 50% des RAMs belegen (da Unraid /tmp auf 50% mapped): df -h /tmp free -h Ich mag das nicht, weil man dadurch andere von Linux gecachte Dateien aus dem RAM wirft. Wenn man /tmp eines Containers mit tmpfs in den RAM mappt, kann man übrigens auch die SSD(s) entlasten: https://forums.unraid.net/bug-reports/stable-releases/683-docker-image-huge-amount-of-unnecessary-writes-on-cache-r733/page/26/?tab=comments#comment-14942

Eigentlich erhält der Stick als Bootlaufwerk sda und dann zählt er an Hand der SATA Ports hoch. Schon komisch, dass das bei dir so durcheinander ist. Dürfte denke ich am BIOS liegen. Linux arbeitet die Devices ja auch nur ab. Nachteile ergeben sich dadurch keine.

@ich777 ?

docker ps --no-trunc