mgutt

Stimmt. Hatte ich übersehen. Mit der 11ten Gen geht das leider nicht mehr.

502 heißt, dass NPM den anderen Container nicht erreichen kann. Bitte die Schritte in "Debug..." abarbeiten: https://forums.unraid.net/topic/110245-support-nginx-proxy-manager-npm-official/?do=findComment&comment=1011152

unRAID stellt diese Werte nicht ein. Das hat wie gesagt nichts mit unRAID zu tun. Kann auch gut sein, dass dein HBA Controller diese Werte gar nicht korrekt durchleitet. Genauso gut kann es sein, dass der HBA die Befehle für die Änderung einfach verschluckt. Am besten mal den Status einer betroffenen HDD direkt an einem Onboard SATA Anschluss prüfen. Wenn es da richtig ist, liegt es am HBA. EDIT: Jo. Offensichtlich ein Bug des HBA: https://forums.unraid.net/topic/94965-adaptec-71605-16i-sata-port-hba-card-for-~50-review-and-how-to-fix-write-cache-disabled/

Kann es sein, dass du Write Cache, eine Hardware Funktion einer HDD mit dem Unraid Cache Pool verwechselst? In wie weit das überhaupt relevant ist und ob die Toshiba überhaupt ihren richtigen Status zurückgeben, kann keiner sagen. Müsstest du mal speziell nach diesem Modell und dem Write Cache suchen. Hat nichts mit unRAID zu tun.

NPM ist für http/https Traffic. Also Port 80 und 443. Wenn du anderen Traffic durch einen Proxy jagen möchtest, musst du dafür einen Stream Host anlegen.

Verstehe ich nicht. Nur weil ein Proxy konfiguriert ist, heißt das doch nicht, dass die feste IP des Containers nicht mehr erreichbar ist?!

Hatte nicht die Zeit mir das anzuschauen. Auf was ich achten würde: - mind. 2x M.2 mit X4 Geschwindigkeit - mind. 6x SATA - Evtl 2.5G LAN Ich selbst will auch ECC RAM, weshalb ich mir nur das W480M kaufen würde, aber das muss jeder selbst wissen, ob einem der Aufpreis das wert ist.

Sieht für mich nicht so aus als würde die GPU verwendet. Bitte mal den Task Manager öffnen und die Nvidia GPU Last sichten während du Fenster bewegst. Da muss bereits die GPU arbeiten. Falls noch nicht geschehen: Lösch die VNC Grafik aus dem VM Template. Dann wird die ganz sicher nicht mehr verwendet.

Einem Linux Server ist die SMB Version egal. Es geht darum, dass man bei SMB1 die Passwörter stehlen kann und falls ein Windows PC SMB1 unterstützt, kann man den evtl sogar hacken, da alle Windows Rechner egal ob Server oder Client, immer auch als SMB Server fungieren. Bei Unraids FTP ist das Problem, dass das Startverzeichnis auf das Root Verzeichnis gelegt wurde und man als Root Nutzer angemeldet ist. Da das FTP dann auch noch unverschlüsselt funktioniert, könnte jemand das Passwort mitschneiden und da man im Root Verzeichnis landet, kann man wirklich alles auf dem Server verändern. Warum das nicht schon lange auf /mnt/user/ftp und auf die normalen Nutzeraccouts geändert wurde und die Verschlüsselung erzwungen, erschließt sich mir nicht. Jedenfalls ist beides Schrott und sollte nicht genutzt werden. Ein Container wäre daher eine gute Idee. Hier gäbe es schon mal einen simplen FTP Server als Container: https://hub.docker.com/search?q=Vsftpd&type=image Und hier zb SMB: https://hub.docker.com/r/dperson/samba

Ja, der F hat keine iGPU. Das sind alles virtuelle GPUs, die durch deine CPU berechnet werden. Der Intel hat deutlich mehr Single und Multicore Leistung: https://www.cpubenchmark.net/compare/Intel-i5-11400F-vs-AMD-Ryzen-5-3400G/4226vs3498 Die iGPU vom 3400G wurde von unRAID und evtl den Containern genutzt (hast du Plex, Jellyfin, etc im Einsatz?). In einer VM konnte man sie gar nicht verwenden. Das ist bei Intel bis zur 10ten Generation aber anders: Ich sage es dir ganz klar: Wegen 20 € Ersparnis einen F zu nehmen, wäre dumm. Du kannst kein GVT-g nutzen, du kannst keinen Container beschleunigen, du kannst keinen Monitor anschließen um Probleme zu analysieren oder ins BIOS zu gehen und du bekommst Probleme, wenn du eine Grafikkarte verbaust und diese in einer VM verwenden möchtest, da unRAID sich automatisch die vom BIOS als primäre GPU gesetzte selbst nehmen will. Also mach dir das Leben nicht unnötig schwer und kauf dir eine CPU mit iGPU.

Was heißt der existiert nicht, wohin hattest du denn die DB wiederhergestellt?! Ich hatte das Kommando bewusst mit Sternchen gepostet. Sollte also sowohl bei dem Original als auch binhex Container ein Ergebnis zurückgeben. Das geht, aber ein Pfad /config gibt es nicht in Linux, weshalb er dann erstellt wird, wenn der Container startet. Schlussendlich heißt das aber, dass Plex beim Transcoding 100% von deinem RAM belegen darf, da /config im RAM erstellt wird. Damit mir Plex den Server nicht killen kann, habe ich in Extra Parameters das hinterlegt (erstellt eine 34GB RAM-Disk unter /tmp und limitiert den RAM des Containers auf 34GB): --mount type=tmpfs,destination=/tmp,tmpfs-size=34000000000 --memory=34G In den Plex Transcoding Einstellungen habe ich dann /transcode in /tmp geändert und schlussendlich heißt das, dass Plex bis zu 34GB meines RAMs nutzen darf. Das hatte ich mal als Maximum beim Transcode von 4K Filmen ermitteln. Plex hat beim neuen Download Feature leider eine Änderung durchgeführt, so dass immer komplette Filme auf dem Server zwischengespeichert werden, bevor der Client sie herunterlädt. Früher war das immer nur so 50MB Clips, die sich dynamisch an den verfügbaren Speicherplatz angepasst haben.

Du hast eine VM und Docker sagtest du. Kannst du zb den VM Dienst komplett deaktivieren? Geht jetzt denke ich nur per Ausschlussprinzip. Ist ASPM wirklich deaktiviert? https://forums.unraid.net/topic/111921-why-is-aspm-disabled-in-unraid-while-its-enabled-in-ubuntu/?do=findComment&comment=1053964

Don't think so. I'm using this since I released my tweak without any problems. I can not see any logs which show a restart of the server?! The first entry is something as follows:

Mach bitte einen eigenen Thread auf und poste mehr Details.

Plex macht ja regelmäßig auch Backups von der Datenbank. Daher wäre es komisch, wenn du das System nicht wieder zum Laufen bekämst Wie machst du denn deine Backups? Sicher, dass der Eigentümer / Gruppe korrekt ist? Es sollte nobody:users sein. Kommando: ls -lah /mnt/user/appdata/*/Library/*/*/*/Databases/ Es gibt auch eine Reparaturmöglichkeit: https://support.plex.tv/articles/repair-a-corrupted-database/ Ansonsten bitte mehr Input. Welcher Plex Container, wie sehen die Pfade des Containers aus, welche Cache Option hat appdata, wo liegen die Dateien von Appdata (also nur Cache oder auch auf dem Array), usw.

Du brauchst vermutlich einen HDMI Dummy, der vortäuscht, dass ein Monitor angeschlossen ist.

Auch das habe ich gelesen, aber ging es nicht darum, dass Nextcloud die Platten geweckt hat? Also dieser Teil des Problems hat sich quasi erledigt, aber du hattest trotzdem noch viele Spinups. So hatte ich das jetzt verstanden. Naja, wie ich auch immer. Ich werde das irgendwann mal untersuchen und mal sehen ob man das Nextcloud-Template von knex666 nicht irgendwie optimieren kann.

Check the section "Debug Server Errors": https://forums.unraid.net/topic/110245-support-nginx-proxy-manager-npm-official/?tab=comments#comment-1011152

Das hatte ich schon richtig verstanden, aber warum ist dein Array nun dauerhaft aktiv?!

Verstehe ich nicht. Wenn /data doch komplett auf dem Cache liegt, wofür ist dann noch das Array im Zugriff?

Da das Plugin auf GitHub gehostet wird, wie sieht es mit dem Laden von der Website aus? Vielleicht ein grundsätzliches Problem deines Providers? Teste auch mal per Terminal ping 8.8.8.8 und ping google.com und curl google.com.

Der Server hat 1 Gbit/s. An dem liegt es nicht. Wenn es das Kabel nicht ist, dann probiere mal den Adapter über den Geräte-Manager vollständig zu deinstallieren und dann neu zu starten. Alternativ Server und Client auf feste IP-Adressen stellen und beide direkt verbinden. Wenn dann 1 Gbit/s geht, hast du den Router als Fehlerquelle ausgemacht (sofern du die Kabel ausschließen konntest).

Die 10 Mbit/s sind dein Problem. Das liegt am Kabel, deinem PC oder dem Router. Da sollte 1 Gbit/s stehen.

Benutzt du Container im br0 Netzwerk? Auch VMs? Welche unRAID Version? Wäre es eine Option den Docker Dienst ein paar Tage abgeschaltet zu lassen? ASPM deaktivieren wäre neben der Deaktivierung der C-States natürlich auch eine Option, die man prüfen könnte. Du könntest außerdem einen Monitor anschließen und darauf hoffen, dass dort was ausgegeben wird. Müsste man allerdings erst das Monitor-Timeout loswerden. Memorytest schon durchgeführt?

It's simple: You can't reach a lower state with so much components. The dGPU alone prevents it.