Ford Prefect

Members
  • Posts

    3460
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Ford Prefect

  1. ....kannst Du mal versuchen eine aktuelle Linux LIVE-ISO zu booten? Geht das Netzwerk dann? ...Fedora wäre mein Favorit. Wenn das System neu ist, kann einfach eine Chipsatz-Revision drauf sein, die so neu ist, dass der Treiber die nicht erkennt. Dagegen spricht halt, dass es schonmal bei Dir lief. ...schau mal hier: Edit2: ....mal das hier durchgelesen?: https://forums.unraid.net/bug-reports/stable-releases/6100-6102-network-lost-after-some-days-working-r1971/?page=2
  2. manuelle Konfig ist durchaus sinnvoll. Bridge entfernen ist mMn keine gute idee, da man dann auf custom-networks bei Docker und VMS verzichtet. Bonding mit einem Port braucht man nicht, aber das würde das System eh erkennen. ...da das System mit einem anderen OS das Netzwerk nutzen kann, kann es ja nur ein Treiber oder Einstellungs-Problem sein. Kannst Du die Diagnostics mal hier einstellen? Komisch ist, dass es ja wohl minidestens einmal mit unraid funktioniert hat....
  3. wenn DHCP nix liefert und auch eine statisch, korrekt eingetragene IP nix liefet, dann liegt es evtl. in der Infrastruktur davor. @jszd...du hast oben von VLANs gesprochen...hast Du VLANs bei Dir am Start?...evtl. die MGMT/Default-ID nicht auf VID=1 gestellt? Ich würde mir mal den Switch-Port angucken, welche PVID dort standard ist und was dann der Router damit macht. Evtl. hast Du, wenn Du Dein altes OS auf dem unraid host bootest (wo ja das Netzwerk funzt) eine andere/explizite VID am Start? Ansonsten bliebe nur noch, das mit ner VM oder Docker was verbogen wurde...sonst bin ich erstmal auch raus.
  4. ...riecht eben danach, dass der Router Heim-und Gastnetz bereitstellt. Diese IP-Netze sollen eben nicht miteinander kommunizieren können. Der unraid "PC" gehört an einen Router Port angesteckt, der die IP im gleichen Netz wie der Laptop vergibt....dann klappt es auch mit dem Zugriff zwischen unraid- PC und Laptop Gesendet von meinem SM-G780G mit Tapatalk
  5. OH, sorry, bitte das Kommando "ip -4 addr" eingeben, statt ifconfig.... Dann kommt die Liste mit Deiner/n IP(s). Du solltest die vom br0 oder eth0 Interface vom unraid sehen. Diese IP solltest Du vom Laptop aus auch pingen können. Im Terminal "ping 8.8.8.8" eingeben....
  6. ...das Ding hat leider keine wesentlichen, technischen Daten verlinkt. Je nach Bestückung des NAS sind 12V (zB mechanische 3.5" HDD - ca. 2-2.5A je HDD Anlaufstrom) oder 5V (2.5" HDDS, SSDs) bzw. 3.3V (NVMe) relevant. Das NT muss die Gesmatleistung bereitstellen, aber die Aufteilung auf die unterschiedlichen Spannungen macht die Pico. Dabei kann durchaus eine Kombo aus 120W NT und 200W Pico noch möglich sein. Ich habe zB diese 200W Version: https://geizhals.de/inter-tech-mini-itx-psu-200w-88882190-a2364184.html?hloc=at&hloc=de - mit einem 120W Leicke, weil diese auch an 5V und 3.3V genug Leistung für meine SSDs und NVMe hat....3.5" HDDs nutze ich nicht in dem System, nur 2.5" - als das Upgrade des Cache von SSD auf NVME dran war...da war das 120W Pico zu schmal.
  7. Wenn Du im GUI Modus auf dem unraid selbst YT nutzen kannst, hast der natürlich Internet, wie Du schon schreibst. Die von Dir beschriebenen "Probleme" liegen dann evtl. auf der anderen Seite...die Ursachen können vielfältig sein. Um die IP des unrais herauszufinden, gib im unraid Terminal (im GUI, rechts oben ein Fenster öffnen - das ">_" Icon anklicken) ein "ifconfig eth0" ein. Dann versuche diese IP vom Laptop aus zu pingen. Wenn das nicht geht, versuche vom unraid CLI mal die 8.8.8.8 (Google DNS) zu pingen. Wenn das dann aber geht, hat unraid I-net, aber unraid und Laptop sind evtl. in zwei verschiedenen Netzen? ...zB. Gastnetz mit LAN4 am Router erwischt, oder Laptop bei Schwiegermutter nur "Gast" ?
  8. ...ich würde nicht in den iptabvles des unraid host rumfummeln. Sowas gehört in eine dedizierte Firewall, durch die dann die VLANs geroutet/gefiltert werden. Hilfsweise geht das mit eine VM auf unraid, der man am besten auch dedizierte Netzwerk-Karten zuordnet.
  9. Wie schon gesagt kenne ich das Plugin nicht. Ich vermute aber, das es einen hybriden Ansatz fährt...also Plugin-Seitig die lokalen Host-Routen verbiegt, aber den Tunnel zum Provider über einen Container macht. Damit auch andere Contiber in dem 172.-er Netzwerk teilnehme können. Damit kann es solche Wechselwirkungen geben. ...der hat auf jeden Fall genug Bumms. Aber auf MT wechsen heisst, dann ist Schluss mit Clicky-Bunti-GUI ... Du scheinst aber mit Linux und IP Stack damit grundsätzlich schon gut vorbelastet zu sein Ja, ich habe im Netzwerk nur noch MT, wobei mir WiFi bei den APs etwas zu "antik" ist - aber mangels Alternativen bleibe ich erstmal dabei. Gerade wurde der hap ac^2-ax angekündigt, mit WiFi6 und 1GB RAM...aktuell schon für um 90EUR gelistet....nicht übel....leider fehlt ihm SFP+ / 2.5G LAN...
  10. unraid läuft im RAM, das heisst solche Änderungen, wie Du sie evtl. über CLI gemacht hast sind nicht persistent. Das musst Du im GO-file scripten...dann wird es beim Start angezogen. Allerdings, bei diesem komplexen Problem evtl. auich abhängig in welcher Reihenfoilge was gesetzt wird und ob die Docker usw schon gestartet sind, damit nix ins Leere läuft. Naja, was Du da gebaut hast ist auch ein wenig von Hinten-durch-die-Brust-ins-Auge. Wenn Du ein VPN zB wie Witreguard oder sowas in der Art bereitstellen oder nutzen willst und auch VLANs am Start hast, gehört das in den Router, nicht auf einen getrennten Host....Du nutzt den unraid Switch/Bridge und die unraud FGirewall mit...sowas würd eman eigentlich mit einer zusätzlochen Firewall, zB als VM machen...my 2 cents.
  11. wird wahrscheinlich automagisch gesetzt, wenn Du die IP und die netzmaske setzt.
  12. OK...und was sagt das Web-Tool (traceroute, mit DNS-Namen und IP - im Container)? ..das WebUI von unraid? OK, klar...diese Route kennt unraid ja lokal. ...sollte so sein, denke ich. Ah, ok dann hat der VPN Container dieses Netz erstellt, auf dem unraid Host. ....mach das mal mit "-n" als Parameter, dann versucht er die IPs nicht zu Namen aufzulösen. So wie es aussieht, hängt der Pfad beim unifi..... Aber der Pfad auf 172.31.x.x vom VL40 sollte ja auch garnicht gehen bzw. übers I-Net zuück...der Container verbindet doch übers VPN (und dort mit der VPN-Provider-IP) Dein Versuch ist also nicht realistisch.
  13. ...und die IP, die im DNS liegt ist die gleiche IP wie im 2ten Versuch? Probier mal das - aus dem FF-Container und auch von einem lokalen Browser im LAN: https://ping.eu/traceroute/ mit DNS-Namen und IP ... welche IP wird Dir oben als "Deine" angezeigt? Die vom VPN-Provider oder Deine eigne WAN-IP oder gar eine Andere? ...und da ist der Browser auf einem lokalen LAN-Client, nicht im FF-Container, richtig? ...ist das unraid interne Docker Netzwerk. Wenn Du die Docker nicht da dran binden willst, verwende custom.bridge und siche Dir die passende Bridge + IP aus. Nur für Docker im LAN...im VL20 und VL40 natürlich das jeweilige GW verwenden. Nicht für wg0, weil das Netz nur zwischen unraid-wg0-Interface und VPN-provider und Deinen wg-Peers verwendet wird. ich nehme an, der VPN-Provider macht natürlich NAT. Ansonsten musst Du bei VLANs alles über den unifi routen und die Netze inkl. GW und regeln konfigurieren.
  14. OK, dann zurück ans Reissbrett....nochmal zum mitschreiben... - Du hast einen Tuunnel zum VPN-Anbieter, via wg0. Die IP des lokalen Peer ist 10.2.0.2 - Du hast einen Container, der ein Peer im Tunnel ist, mit ner 10.2.0.xxx IP - der Container geht mit dieser IP über den VPN-Tunnel ins Internet - Du möchtest, dass eine App/ein Prozess in dem Container auf Deine anderen, im .40.xxx gehosteten Container verbindet. Diese Container sind über den NPM .40.200 erreichbar; der NPM ist über eine Portweiterleitung für Ports80/443 aus dem I-Net erreichbar. Stellen wir uns also die Frage, ob A) der wg-container überhaupt den NPM erreichen kann (Edit: überhaupt über den Tunnel ins I-net zu Dener WAN-IP geht - die ja auch die WAN IP ist, die Dein VPN Anbieter sieht) und B) welchen Rückweg die Pakete zur IP 10.2.0.xxx des Containers nehmen (würden).... Hilf mir mal mit dem NPM, ich nutze sowas nicht...welche IP sehen die angesprungenen Container im .40.xxx...die IP des unifi, des NPM odder was?
  15. Das ist schonmal ein Fehler. Wenn der Port am Unifi das 40er als tagged VLAN führt, der Port in unraid aber dies nicht als VLAN kennt, sind die Pakete von unraid mit der .40er IP un-tagged. Du musst diesen unifi-Port also auch bei untagged auf ID=40 forcieren, damit die Pakete im VLAN40 bleiben. So wie Du es schildert landen sie wohl in Deinem default VLAN, also in Deinem LAN Segment - aber mit ne IP aus dem 40er. Also deine Peers auf der anderen Seite des wg0 Interfaces bekommen eine IP aus dem wg-Pool (10.2.0.x) Dieses IP-Segment musst Du auch in der Unifi bekannt machen...mit ner Gateway IP des unRaid Servers...da hast Du jetzt mehrere LAN, V20, V40....such Dir die passende aus. Wenn Du zwischen Hosts/Dockern/VMs in unterschiedlichen VLANs kommunizieren willst, muss das durch die Unifi-Firewall. Daher muss diese auch alle IPs kennen. gut. Siehe oben. Siehe das erste tagged/untagged problem. Der Firefox Container ist im LAN...der VL40-Port des unraid ist nicht im VL40. Egal ob Du es eigentlich willst oder nicht. Vielleicht solltest Du mal ausprobiren, welche Route die Pakete nehmen. Es funktioniert ja normalerweise so, dass Du in der Firewall alles verbietest, was nicht explizt erlaubt ist. Evtl. hast Du es andersrum designed? Alles erlauben, was nicht verboten ist? Stell den Firefox container mal auf custom bridge und vergib eine passende IP...LAN, VL20, VL40...und versuche dan zwischen den Segmenten zu pingen. Dann enable das Routing zwischen Segmenten, Schritt für Schritt. Ich vermute halt, dass Du im LAN Segment das originäre .1.XXX und das .40.xxx Segment fährst und keine VLANs (tagged/untagged "Problem"). Ist von hier aus schwer zu sagen, wo das Problem sonst noch sein könnte. Ohne VLANs in unraid, wird Traffic zwischen Dockern/VMS/unraid host lokal geroutet, wenn es Interfaces in den jeweiligen Segmenten gibt. Nur bei VLANs nicht; da muss es an den Unifi, wenn man zwischen IP-Segmenten kommunizieren will....alles über die jeweilige Default route.
  16. Neeee, leider nicht ich nutze weder Wireguard / Proton-VPN auf unraid, noch NPM. OK, ich nehme mal an, br1 auf unraid ist gar kein VLAN, sondern nur ein LAN mit der IP aus dem VLAN40? ...und welches IP-Segment läuft auf den Endpunkten des Tunnel? Welche Access-Listen sind in den wireguard Peers jeweils definiert? Welche IP-Segmente/(V)LANs kannst Du über den Tunnel erreichen/pingen? ...also läuft er im Bridge/Host-Mode? Hast Du ihn mal in custom-bridge (br0) und dedizierter IP aus dem LAN Segment konfiguriert? Geht es dann? Hast Du in der UDM das Routing und die Firewall korrekt eingestellt? VLAN40 als DMZ sollte ja von innen, zB aus LAN noch erreichbar sein, aber nicht andersrum. Bedenke, dass da auch die Tunnel IPs konfiguriert werden müssen, die auf die DMZ gelangen dürfen....oder macht das wg0 Interface NAT?
  17. Das Manual ist hier, einbauen: https://wiki.unraid.net/Manual/Storage_Management#Adding_disks ... und ausbauen: https://wiki.unraid.net/Manual/Storage_Management#Removing_disks Wie man erklennt, ist beim ausbauen *kein* umkopieren enthalten; das musst Du selbst machen - entweder weil Du vorher Backups hast, oder - und das ist der "Trick", da jede Daten-Disk im Array ja einzeln formatiert ist und beim ausbau nicht gelöscht wird - später, mit der ausgebauten Paltte als "Backup-Ersatz". Wenn die Disk ausgebaut ist / sind, kannst Du diese über das unassigned Devices Plugin im System sichtbar machen und dann normal, zum umkopieren darauf zugreifen. Zum Beispiel über die Kommandozeile. Quelle sind die Daten aus der remote DiskX und Ziel Dein Array unter /mnt/user (wenn die shares gleich geblieben sind). Hier die Anleutung zum kopieren unter Erhaktung von rechten und vor allem Time-Stamps: https://fabianlee.org/2018/10/15/linux-copy-a-directory-preserving-ownership-permissions-and-modification-date/ Das wäre auch eine Möglichkeit. Also erst einbauen, dann unbalance, dann ausbauen
  18. ..Du hast doch noch einen Slot und Port frei, oder? Dann würde ich die normale Prozedur anwenden... - die neue 6 TB rein - dann die 4TB raus - dann die 2 TB raus -> siehe Manual. Edit: natürlich danach die nun externen Disks über unassigend devices mounten und Daten zurück aus Array kopieren (Datumstempel behalten).
  19. ...die Betonung lliegt auf ggf....selbst wenn DU die Netzwerkverbindung mit mehr Bandbreite ausstattest, musst Du den use-case bedenken. Wenn die Verbindung schneller ist als Dein Array und die Daten nicht in den Cache-Pool passen, wird Dich das auch ausbremsen. Ja, das wird nix...ausserdem ist SMB single-threaded...FTP oder NFS (oder eben rsync) würde dann evtl. was dabei bringen. ...einfach rsync nehmen und "laufen lassen".
  20. ...geht doch Ich würde evtl noch ein kurzes "sleep" zwischen down- und up-Befehl setzen...better safe than sorry.
  21. Evtl. geht das mit dem unassigned devices Plugin? Dort kann man zumindest entfernte SMB/NFS Server mounten und auch wieder als share freigeben....ob da nun/schon Webdav unterstützt wird, weiss ich nicht. Das Ganze ist dann aber eher so ein "von hinten durch die Brust ins Auge" Ding Evtl. solltest Du eher darüber nachdenken sowas wie Nextcloud als Frontend-Service zu verwenden....gibt es auch in den Apps. Damit sind dann wieder eigene, weit granularere Freigaben und - ich glaube - auch Verschlüsselung möglich.
  22. Nein, es verhält sich etwas anders, mit Docker, Containern und dem "Appdata" Verzeichnis, wie es bei den Dockern unter "APPS" üblich ist. Kurze Version: Dein/Dieser Container braucht sowas wohl nicht....es ist ein Verschlüsselungs-Service und der Key ist immer das Passwort, welches Du ja in den Variablen "konstant" hälst und in der Konfig extern definierst, übergibst (aber nicht pflegst, dh Passwort später mal ändern ist nicht "in place" möglch). Damit muss der container, zmindest mein Verständnis, nichts eigenstängiges (eine Konfiguration o.ä) speichern, was einen Start/Stopp/Update überleben muss. Lange Version: nirgendwo. Installiert wird das Docker-Image. Dieses wird in Deiner Docker-Installation gespeichert. Entweder im Docker.IMG oder im Docker Verzeichnis. Ein Docker-Image ist wie eine kleine VM, also wie das ISO oder vdisk dazu. Der Container ist die gestartete, laufende Instanz dieses Image und ist immer nur im RAM....sozusagen die gestartete VM. Nein, da sind sie nicht. Siehe oben. Das Verzeichnis /mnt/user/appdata/<docker name> ist nur ein Konstrukt, eine Konvention um die Pfade der Docker einfacher zu finden, wenn deren Container Daten zur Laufzeit nicht im RAM, sondern auf dem Array/dem Cache ablegen/speichern sollen um damit nach einem Stop/Start diese Daten wiederzufinden und weiter benutzen zu können. Dahinter versteckt sich ein sogenanntes Docker Volume: https://docs.docker.com/storage/volumes/ Das Dateisystem des Containers, dieser Mini-VM ist dabei ebenfalls, vereinfacht ausgedrückt, immer im RAM...wenn eine Datei zur Laufzeit benutzt wird, wird sie entweder gelesen oder auch geändert/beschrieben. Wird diese nur gelesen, wird sie vom Docker-Image "kopiert"....wird sie verändert, bleibt sie im Docker-Image unverändert, aber die geänderte Version bleibt im Container, im RAM, quasi darübergelegt aktiv. Wird der Container gestoppt/beendet, geht die geänderte Datei, weil nur im RAM, verloren. Ein Docker Volume "mappt" nun ein externes, "echtes" physisches Verzeichnis in den Pfad innerhalb des Containers. Beispiel: Im Container des Docker mit Namen X sind alle Einstellungen, wie bei fast allen Linux basierten Systemen, in Dateien unterhalb von /etc gespeichert. Nun wird ein Docker Volume für dieses Verzeichnis aus dem echten unraud Array da hinein gemappt, zB mit Parameter /mnt/user/appdata/DockerX:/etc. Damit landen alle neuen, geänderten Dateien aus /etc des Containers im Verzeichnis /mnt/user/appdata/DockerX. Wird der Container beendet und dann neu gestartet, sind die Dateien dann immer noch da, weil sie physisch im Arra liegen. Also: Nein, ist es nicht. /cryptomatorDir ist das Verzeichnis *im* Container. Wenn Du also zB ein Share erstellst (mit oder ohne Cache), Namens "myVault", dann taucht es unter /mnt/user/myVault in Unraid auf. Damit dieser Container funktioniert, musst Du also den VAULT_PATH auf "/mnt/user/myVault:/cryptomatorDir" konfigurieren. Wird der Docker gestartet, sollte der Container über WebDAV, dem PORT=8181 und unter VAULT_NAME erreichbar sein: <unraid IP>:8181/<VAULT Name> Der Container mappt einfach nur das Verzeichns und legt wohl keine eigenen Konfog-Dateien ab. Daher brauchst Du /mnt/appdata/cyptomator dafür nicht. Wie gesagt, ich habe es noch nicht probiert, aber ich gehe mal davon aus, dass der WebDAV-Client beim Verbindungsversuch nach dem VAULT_PASS fragt. Wenn Du aber alles richtig konfiguriert hast, liegt es vielleicht am WebDAV Client, mit dem Du zugreifst?
  23. ...sollte von der Seite her passen. Evtl hast Du beim Inhalt der Parameter einen Bock geschossen? Kritisch ist wohl der VAULT_PATH ...nicht den Doppelpunkt zwischen beiden Pfaden vergessen, also_ <dein unraid pfad, zB /mnt/user/meinCryptVault> : <der Pfad aus Sicht des Containers, zB /cryptomatorDir> - und ohne Leerzeichen, etwa so -> /mnt/user/appdata/cryptomator:/cryptomatorDir ...ich hab das Ding aber auch noch nicht ausprobiert
  24. ...dann würde ich das eher auch nur fürs Backup intregrieren? wie hast Du das gelöst? Wenn das ein Script ist, vor dem Backup den WG-Tunnel starten und danach wieder beenden. ich kenne die WG-Tunnel-Lösung von unraid da nicht im Detail...ich dachte bisher, es sei eigentlich nur ein Docker-Container - den man dann starten/stoppen könnte. ...es gibt das User-Scripts Plugin: Damit sollte das möglich sein, ein einfaches/beliebig kompliziertes Script einzuhängen. Ich denke, es sollte die WG-Tunnel-IP der Gegenstelle pingen...wenn das fehlschlägt den Tunnel restarten. Evtl. Retries und Timeouts mit berücksichtigen und im Zweifel einen LogEintrag oder eine Email senden. Man könnte das Script auf beiden Unraid-Seiten einsetzen, wenn der Endpoint der Peers auf beiden Seiten eingerichtet ist. Dann gibt es die doppelte Chance, das eine IP greift (macht nur Sinn, wenn beide eine echte IP und kein ds-lite haben).