Pillendreher

Members
  • Posts

    51
  • Joined

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Pillendreher's Achievements

Rookie

Rookie (2/14)

2

Reputation

  1. Das Problem mit den aufwachenden Festplatten gibt es ja schon seit nem halben Jahr. Die letzten Beta Versionen 6.9 hatten das schon. Man hat aber nicht wirklich auf entsprechende Meldungen reagiert. @mguttIch werde mal dein Skript bei mir testen.
  2. Ja, das kenne ich. Solange aber kontinuierlich der Fortschritt angezeigt wird, konnte ich mich in der Vergangenheit auch darauf verlassen. In meinem Desktop läuft eine WD Black 750, in meinem Laptop eine Corsair MP510 SSD. Daran dürfte es nicht liegen Nein. Die *.img Datei war aber hier nur als Beispiel ausgewählt. Es trat genauso auch bei allen anderen testweise übertragenen Dateien auf.
  3. Wenn sich aber in irgendwelche Konfigruationsdateien irgendetwas einschleicht, dann kriege ich das ja nicht mehr weg außer durch ein Zurücksetzen des Systems. Ich hatte z.B. eine Fehlermeldung vor ein paar Monaten ne Fehlermeldung im Sleep Plugin, die einfach nicht verschwinden wollte - irgendwas muss da beim Dynamix Plugin kaputt gegangen sein. Nach einem Neuaufsetzen des USB Sticks war der Fehler weg
  4. Morgen! Nachdem ich gestern Abend mehrere Stunden lang den Datendurchsatz der Fritzboxen getestet und sogar mal die Netzwerkdosen geöffnet hatte, kann ich nun mit ziemlicher Sicherheit sagen, dass irgendwas mit meinem Unraid Server und Datenübertragungen nicht stimmt. Mir war das ganze schon vor gut 2 Wochen aufgefallen, als ich nach einer Neuinstallation von Windows Daten zurückholen wollte und nicht über 50 MB/s hinauskam. Ich hatte es erst auf die verwendete Festplatte geschoben, aber da das Ganze auch bei den SSDs im Server auftritt, kann es das nicht sein. Den verwendeten PC kann ich auch ausschließen, da es am Laptop genauso auftritt. Folgendes ist das Problem: Über SMB/FTP geht ein Upload mit mehr oder weniger vollen 1 GBit/s durch: Sobald ich aber Sachen vom Server holen möchte, komme ich nicht einmal mehr ansatzweise in diesen Bereich: Ich hattet nun erst die Router bzw. die Kabel im Verdacht, aber das kann ja eigentlich nicht das Problem sein, da über iperf die Leitung mehr oder weniger voll ausgelastet wird: Wenn hier also die Pakete nicht an dieser onimösen Grenze von gut 50 % der Gbit Verbindung hängen, kann es ja eigentlich kein direktes "Hardware-Problem" sein. Ich kann mir beim besten Willen aber nicht vorstellen, woran das Ganze liegen soll. Folgendes habe ich schon ausprobiert, jedoch ohne Besserung: -Neustart -Stoppen aller Docker-Container -Deaktivieren von Wireguard -Stoppen der W10 VM -Stoppen des Arrays, deaktivieren von Dokcer/VM/SMB/FTP, Einbinden einer der Fesplatten als unassigned device (FTP erneut aktiviert) -Undervolting rausgenommen Hatte jemand von euch schon einmal dieses Problem? Ich habe ehrlich gesagt wenig Lust, jetzt schon wieder alles neu aufzusetzen auf dem Server. Das wäre jetzt in 6 Monaten das 4. oder 5. Mal und jedes Mal, weil irgendwas plötzlich nicht mehr funktioniert... Grüße EDIT: Das gibt es nicht...da mir plötzlich die Platte, die ich über unassigned devices eingebunden hatte, als "unmountable" angezeigt wurde, hatte ich eine neue Konfiguration erstellt und das System neu gestartet. Und siehe da: Der Download läuft wieder mit nahezu voller Geschwindigkeit. Bin mal gespannt, ob das Problem jetzt dauerhaft verschwunden ist.
  5. Ich hab doch aber nicht br0, sondern ein eigens erstelltes Netzwerk?!
  6. Nö, ganz normal eingegeben. Hab es gerade testweise auch noch einmal mit Edge probiert: Die Erfolgsmeldung erscheint auch dort, ist also nicht nur ein Überbleibsel vergangener Tage im Firefox. Tatsache, jetzt geht es - wie kann das sein?! Wenn die Ports jeweils passen, kann doch nicht 444 fehlschlagen und 443 funktionieren...Oder hat das womöglich etwas mit "internal" als Parameter bei der Netzwerkerstellung zu tun?
  7. NPM lauscht auf 1880 und 18443. Die Fritzbox leitet 443 auf 18443 und 80 auf 1880 des Unraid Servers weiter, der aber jetzt natürlich eine andere IP-Adresse als der NPM Container hat (192.168.178.24 vorher, jetzt laut ifconfig des Containers "inet addr:192.168.179.2". Sollte es aber ein Problem mit den Portweiterleitungen geben, dürfte doch eigentlich nicht diese NPM Seite beim Aufruf meiner externen IPv4-Adresse kommen, oder?
  8. Also im Moment ist das Ganze so konfiguriert: MariaDB und Nextcloud sind in Unraid dem internen Netzwerk mit festen IPs zugeteilt (192.168.179.3 für MariaDB, 192.168.179.4 für Nextcloud). Nginx Proxy Manager ist in Unraid als "Bridge" konfiguriert und gleichzeitig mit dem internen Netzwerk verbunden: root@Tower:~# docker network inspect isoliertes_netzwerk [ { "Name": "isoliertes_netzwerk", "Id": "***", "Created": "2021-05-01T09:50:21.852711971+02:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "192.168.179.0/24" } ] }, "Internal": true, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "***": { "Name": "NginxProxyManager", "EndpointID": "***", "MacAddress": "***", "IPv4Address": "192.168.179.2/24", "IPv6Address": "" }, "***": { "Name": "mariadb", "EndpointID": "***", "MacAddress": "***", "IPv4Address": "192.168.179.3/24", "IPv6Address": "" }, "***": { "Name": "nextcloud", "EndpointID": "***", "MacAddress": "***", "IPv4Address": "192.168.179.4/24", "IPv6Address": "" } }, "Options": {}, "Labels": {} } ] Wenn ich meine externe IPv4-Adresse aufrufe, erscheint Folgendes: Nginx Proxy Manager scheint also zu laufen. Nextcloud scheint wie gesagt auch eine Verbindung zu MariaDB hergestellt zu haben, denn der occ Befehl "geht durch", bringt also keine Fehlermeldung. Im Nginx Proxy Manager sieht meine Weiterleitungs-Konfiguration so aus: Und Nextcloud ist in Unraid als Docker Container so konfiguriert: Tut mir Leid, aber verstehe nicht, was du mir hier empfiehlst. Ich habe in der Fritzbox ja bereits die Ports 443 und 80 für den Unraid Server geöffnet. Reicht das denn nicht? Ah, das würde darauf hindeuten, dass die Konfiguration nicht passt, also die Weiterleitung im Nirgendwo landet. Wie passt das aber damit zusammen, dass ich vom Nginx Proxy Manager Container erfolgreich einen Ping Richtung 192.168.179.4 (Nextcloud) schicken kann, und gleichzeitig der Nextcloud Container erfolgreich einen Ping Richtung 192.168.178.24 (Unraid Server) schicken kann? Andererseits frage ich mich aber: Müsste der Ping zum Unraid Server gerade nicht verhindert werden?!
  9. Ich wollte das mal bei mir ausprobieren, aber leider geht so manches nicht. MariaDB, Nextcloud und NginxProxyManager hängen alle in einem internen Docker Netzwerk. Soweit so gut. Über die jeweilige Container-Console erreiche ich per curl bzw. ping die jeweils anderen Container, d.h. sie sehen sich und können miteinander kommunizieren. In der config.php von Nextcloud habe ich die IP Adresse von MariaDB geändert, was scheinbar auch funktioniert hat, denn der occ Befehl im Nextcloud-Container geht durch und wirft mir nicht wie vor der Änderung Datenbank-Fehler aus. Mein Problem ist nun aber: Obwohl ich in der Proxy Host Datei für Nextcloud die IP Adresse auf den neuen Adressraum des isolierten Containers geändert habe, klappt die Weiterleitung von der duckdns Adresse nicht. Darüber hinaus kann ich auch das Webinterface des ProxyManagers nicht öffnen - in Unraid möchte er sich noch über die alte IP-Adresse verbinden und selbst wenn ich die neue IP-Adresse eingebe und mit dem weitergeleiteten WebIF-Port versehe, kommt keine Verbindung zustande. Hast du hierfür noch irgendwelche besonderen Einstellungen vorgenommen? EDIT: Oh Mann, ich Depp. Das wird daran liegen, dass das Netzwerk keine Verbindungen von außen zulässt - "ping" von meinem Laptop aus landet auch im Nirgendwo... EDIT2: Mein Hauptfehler lag darin, den NginxProxyManager in Unraid dauerhaft dem internen Netzwerk zuzuweisen. Dein "network connect" Befehl von oben brachte Abhilfe. Jetzt komme ich auf das WebIF des NginxProxyManager wieder drauf, jedoch klappt die Weiterleitung von der duckdns Adresse weiterhin nicht: Es kommt eine Verbindung zustande, jedoch erscheint dann eine "502 Bad Gateway" Fehlermeldung. Mal schauen, woran das liegt...
  10. Well, forgive my ignorance, but I always assumed that NPM was a sort of security measure. You know, instead of exposing the docker container "as is". So I could theorically open port 80 to get the certificate once and then close it again until the certificate expries?
  11. I've got a quick question: I've made my Nextcloud container available for external use. Right now I'm forwarding port 443 and NPM forwards the incoming requests to the container. Since 443 is very common, I wanted to at least avoid port scans for common ports. Disabling the port forwarding of port 80 in my router makes NPM unaccessable as far as I can tell, so this does not seem to work. Is there any way to go away from forwarding port 80 and 443 and move to let's say 20080 and 20443?
  12. Ich hab mir das mal angesehen, verstehe aber nicht so recht, was dieser Docker macht. So wie ich das jetzt laienhaft verstehe, schiebt er sich dazwischen mit einer VPN Verbindung. Auf welche VPN Verbindung bezieht sich das Ganze aber? Kann man da seine VPN Daten (Wireguard) des Unraid Servers eintragen? Und wie bin ich dann "geschützter" im Vergleich zu vorher?
  13. Danke euch beiden, schau ich mir mal in einer ruhigen Minute an! In der Zwischenzeit habe ich heute zufällig rausgefunden, dass ich über die "MyFritz" APP auch eine VPN Verbindung zur Fritzbox herstellen kann, sodass ich noch eine Alternative zu Wireguard über den Unraid Server habe
  14. Und dieses Netzwerk erstelle ich stinknormal mit "docker network create"? Oder ist das komplizierter?