mgutt

Hairpinning is a technique where you can access a local client by an other local client through the public ip of the internet connection. But this works only if the router supports this feature. This should work for any docker network type, as the traffic is coming from "outside" of the network (the router routes it back through its firewall, that's why even the routers port forwarding works). But br0 (and using the local IP in the DNS) should be the better method. Regarding crashes: Did anyone tested to set a mac address? As my router gets really confused about clients (containers) having only an IP, I thought this could be a reason for this problem?!

Ah ok. Yes, br0 with fixed IP would be a solution. Or changing Unraid's default ports. Or you set your public IP for the domain. By that your local traffic is "hairpinned" back through your router. I prefer changing Unraid's port. By that it would be even possible to use an additional domain for the unRAID GUI.

Wenn du "/Filmname (2021)/Filmname (2021).mkv" machst, dann sollte deine Trefferquote bei 99% liegen. Ich mache es jedenfalls nicht anders. Man kann noch "tt123456", also die ID von IMDB in den Dateinamen packen, aber das brauchte ich noch nie. MP4 habe ich keine. Ich will ja den Film im Original haben.

Ich habe heute testweise IPv6 in meiner Fritz!Box deaktiviert: Auf Server und Clients habe ich IPv6 aktiv gelassen. In meiner jugendlichen Naivität ging ich davon aus, dass damit IPv6 nicht gehen wird. Unraid behauptet auch keine IPv6 zu haben: hostname -I 192.168.178.9 192.168.178.8 172.17.0.1 172.20.0.1 192.168.122.1 Aber wenn ich von meinem Client einen Ping absetze, dann hat Unraid eine so genannte Link-Local-Unicast-Adresse: Die IPv6 kam mir irgendwie bekannt vor und als ich sie mit meiner MAC-Adresse verglich, kam die Erleuchtung: Die "fe80" ist also nichts anderes als eine IPv6 mit integrierter MAC-Adresse und das nennt sich wiederum EUI-64. Doch woher kommt die nun? Weil wenn ich die Fritz!Box anpinge, dann wird die nicht über eine IPv6 angesprochen: Ich habe dann mit arp -a die MAC-Adresse der Fritz!Box ermittelt und mit einem Converter eine IPv6 daraus gebaut und an die kann ich ebenfalls Pakete über IPv6 senden: Rein vom Gefühl her ist mein Servername mit der IPv6 in irgendeinem DNS Cache. Aber wie kann das sein, wo ich doch alles neu gestartet habe? Beim Client habe ich schon mit "ipconfig /flushdns" versucht den Cache zu löschen. Oder kann es sein, dass der Server selbst diese IPv6 (über wsdd) verbreitet? EDIT: Ja ist denke ich so, denn ich habe den Server gerade neu gestartet und in der selben Sekunde kann der Name nicht mehr gefunden werden: Nachdem Neustart und damit IPv4 Only in Unraid, habe ich das Problem nun nicht mehr. Gut. Ich gehe also denke ich recht in der Annahme, dass man IPv6 nicht wirklich global deaktivieren kann, sondern immer nur pro Client?

There is no "best practice". I changed Unraid's ports as described here, but everyone can do it as they want. I do not really understand why this happens. If NPM runs as bridge with for example port 8443 and you forward port 443 in your router to 8443, then the complete traffic is forwarded to NPM. Now you create a new proxy host for npm.example.com and its target is the server ip + port 81, which is the UI port of NPM. So the traffic goes this way: publicIP:443 > unraidIP:8443 > dockerBridge:8443 > npm:443 > npm:81 Or did you change the port 81 through the bridge? Then use your changed port.

Welche Docker Netzwerke können andere erreichen? Ich habe mir mal die Mühe gemacht und gefühlt 100 Container mit unterschiedlichen Netzwerken gestartet und dann mit "curl <IP>:<Port>" versucht die jeweils anderen Container, Unraid, den Router oder das Internet zu erreichen. Die folgende Tabelle zeigt das Ergebnis, was allerdings nur gilt, wenn "Host to Custom Access" in den Docker Einstellungen deaktiviert wurde. Eventuell finde ich auch noch die Zeit die anderen Varianten auszuprobieren. Source = Der Container von dem die Anfrage kommt Target = Der Container / das Ziel an die die Anfrage ging Denkt dran, dass man Container mit dem Befehl "docker network connect <Netzwerkname> <ContainerName>" mit Netzwerken verbinden kann. Dadurch können manche Einschränkungen also wieder aufgehoben werden.

Mehrzahl? Sicher, dass auf den Platten keine Shares liegen, die in Nextcloud verwendet werden? Sicher, dass der system und appdata Share komplett auf der SSD liegt? Kannst du über Shares > Ordner-Symbol prüfen. In der Spalte "LOCATION" steht wo die Ordner liegen. Sollte dann entsprechend nur "cache" sein.

Das gilt dann aber für SATA SSDs und nicht für an VFIO gebundene NVME oder? Weil in dem Video ist die NVME weg, sobald sie an VFIO gebunden wurde.

Stimmt. Gerade bei Surveillance ist eine USV meiner Ansicht nach Pflicht. Denn sonst versucht der Einbrecher zB über eine Außenlampe den FI auszulösen und evtl ist da auch gleich dein Server/Router dran und du bekommst niemals die Benachrichtigung. Ehrlich gesagt kenne ich Blue-Iris nur von früher und da war Direct to Disk noch nicht so omnipräsent wie heute (damals konnte man das Bild nur manipulieren, wenn man D2D nicht nutzte und die RAM-Auslastung war entsprechend hoch). Ich habe auch gerade gelesen, dass der große Original-Stream nur noch bei Alarmen gespeichert wird: https://ipcamtalk.com/threads/5-4-4-0-update-new-triggered-continuous-record-setting.56058/

Hast du mal beide Anwendungen im Root der ISO ausgeführt? Damit werden eigentlich alle Treiber automatisch installiert. Vielleicht vermittelt diese Anleitung auch noch etwas, was du noch nicht wusstest: https://forums.unraid.net/topic/112374-windows-1011-vm-installationsanleitung/ Wie hast du die NVMe an eine VM durchschleifen können, wenn du sie in UD siehst? Muss man sie dafür nicht erst an VFIO binden? Ich kenne das "PASSED THROUGH" von UD tatsächlich nicht. Ich kenne nur den Trick, der hier ab 13:00 beschrieben ist: Oder ist das schon wieder "veraltet"?

32GB wären bei einem 5 Mbit/s Stream immerhin 14 Stunden Videomaterial: https://www.heise.de/netze/tools/bandbreitenrechner/ Wenn ich also vier Kameras im Einsatz habe, bräuchte ich die RAM-Disk nur alle 3 Stunden leeren, was wiederum 5 Minuten dauert. Also läuft die HDD statt 24/7 nur 8x 5 Minuten pro Tag (wenn man parallel den Spindown absetzt). Hat auch den Vorteil, dass man keine spezielle Surveillance HDD braucht und man sequentiell ohne Defragmentierung wegschreiben würde. Natürlich nur rein theoretisch, weil ich wie gesagt nicht weiß ob man das mit der jeweiligen Software hinbekommt. Vielleicht kann man sowas mit FUSE realisieren!? Also RAM-Disk liegt vor HDD-Array wie Unraid das auch mit dem Cache macht?

Also mit pcie_aspm=off ist Ruhe. Aber das geht natürlich zu Lasten des Stromverbrauchs. Wie viel kann ich gerade nicht sagen. Läuft zu viel ^^

Aktiviere mal die Mover Logs und dann starte den Mover. In Tools > Syslogs siehst du dann alle Fehler, die der Mover ausgibt.

2x 16GB gehen auf jeden Fall. Habe ich schon mehrfach gelesen. TRIM? Führe mal das aus: fstrim -v /mnt/cache Falls es das ist: TRIM Plugin installieren! Was du auch noch machen könntest ist den RAM Cache vergrößern. Dazu den Config Editor installieren und über Tools die /boot/config/go um folgende Zeilen ergänzen: # ------------------------------------------------- # Optimize write cache # ------------------------------------------------- sysctl vm.dirty_ratio=50 sysctl vm.dirty_expire_centisecs=3000 Die selben Zeilen auch mal über das WebTerminal ausführen. Danach ist dein Schreibcache ~8GB groß (50% vom freien RAM). Mehr dazu auch in diesem Post/Video: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-951565

Wenn das der Fall ist, dann hast du die Shares auf "Prefer" gestellt. Alles was auf "Prefer" gestellt ist, wird komplett auf den Cache geschoben. Denk dran: Dateien sind immer nur auf dem Cache oder dem Array.

Das ist eben der Punkt. Entweder schreibt man sich seine SSD kaputt oder man lebt mit der ständig drehenden HDD. Eine VM mit großem RAM oder einer RAM-Disk erspart dir beides. Allerdings hängt es eben von der Software ab, ob sie das auch nutzen kann. Die Alternative dazu wäre eine Enterprise SSD, die für schreibintensive Anwendungen gebaut ist. Es kommt außerdem darauf an, ob man alles aufnehmen möchte oder nur die Videos mit Alarm. Ich stelle mir das zB so vor: Die Streams werden alle durch einen Prozessor gejagt um Alarme zu ermitteln (bis hier hin sind sie noch auf gar keinem Datenträger). Alle Streams mit Alarm landen dann im RAM und nach Ablauf von X Stunden werden sie in einem Rutsch auf eine HDD weggeschrieben. @Rockikone Hast du bei Frigate eine permanente Schreiblast auf dem Datenträger oder schreibt der erst, wenn die Person erkannt wurde? Was ist, wenn man zB die 10 Sekunden von vor der Personenerkennung auch in der Aufnahme haben will (bei X hochauflösenden Kameras braucht es dafür ja entsprechend viel Platz, sei es im RAM oder im Datenträger).

And 7818 is forwarded by your router's public port 443? And what about 80? It points to which port? This sounds you forwarded your public port 80 to NPMs Port 81, which is of course wrong. NPM has three ports. 80 (http), 443 (https) and 81 (http GUI). GUI is only for local admin access.

At the moment I try to enable SMB Multichannel when my Client has 10G LAN and my server has two 1G LAN ports. What I tried: Enabled Multichannel and added speed capabilities per adapter/ip: Checked on the client if both IPs have been found and selected for Multichannel: But finally it does not work as eth1 is not used: Then I reminded that it is not possible to mix RSS and non-RSS scenarios: https://docs.microsoft.com/en-us/archive/blogs/josebda/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0 So the first step was to disable RSS on the clients adapter: But still no activity on eth1: Then I did: - disabled IPv6 on the server and on the client - rebooted server and client And now it works: Was it because of disabling RSS? No, after re-enabling IPv6 and rebooting, it does not work anymore: As you can see "thoth" resolves to an IPv6 address. I tried to copy to both IPv4 addresses of the server, but it does not enable SMB Multichannel: This is strange as for both IPs both target server adapters were found: Maybe SMB multichannel works only for SMB server names? Let's try it out by adding "tower" as a new server name for .8: again no success after copying to "tower": Next step was to disable IPv6 in the network adapter properties: Even rebooting the client does not help... I did a little bit research and on this blog I found someone who gets IPv6 addresses if he executes Get-SmbMultichannelConnection: https://blog.chaospixel.com/linux/2016/09/samba-enable-smb-multichannel-support-on-linux.html So I think my problem is that this command returns in my case only IPv4 addresses even if the clients network adapter has IPv6 enabled. But why 🤔 The smb service on Unraid listens to IPv6: netstat -lnp | grep smb tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 30644/smbd tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 30644/smbd tcp6 0 0 :::139 :::* LISTEN 30644/smbd tcp6 0 0 :::445 :::* LISTEN 30644/smbd And the client resolves with "ping" the smb server name with an IPv6 address, too.... Just for fun I added the IPv6 addresses to the smb conf: interfaces = "fd00::b62e:99ff:fea8:c72c;speed=1000000000" "fd00::b62e:99ff:fea8:c72a;speed=1000000000" "192.168.178.8;speed=1000000000" "192.168.178.9;speed=1000000000" SMB listens now only to these specific IPs: netstat -lnp --wide | grep smb tcp 0 0 192.168.178.8:139 0.0.0.0:* LISTEN 24774/smbd tcp 0 0 192.168.178.9:139 0.0.0.0:* LISTEN 24774/smbd tcp 0 0 192.168.178.8:445 0.0.0.0:* LISTEN 24774/smbd tcp 0 0 192.168.178.9:445 0.0.0.0:* LISTEN 24774/smbd tcp6 0 0 fd00::b62e:99ff:fea8:c72a:139 :::* LISTEN 24774/smbd tcp6 0 0 fd00::b62e:99ff:fea8:c72c:139 :::* LISTEN 24774/smbd tcp6 0 0 fd00::b62e:99ff:fea8:c72a:445 :::* LISTEN 24774/smbd tcp6 0 0 fd00::b62e:99ff:fea8:c72c:445 :::* LISTEN 24774/smbd And ironically the Windows client now reaches the server through one (?!) IPv6: Get-SmbMultichannelConnection Server Name Selected Client IP Server IP Client Interface Index Server Interface Index Client RSS Capable Client RDMA Capable ----------- -------- --------- --------- ---------------------- ---------------------- ------------------ ------------------- THOTH True 192.168.178.21 192.168.178.9 13 11 False False THOTH True 2003:e0:a71d:5700:e988:c813:e0d4:a16a fd00::b62e:99ff:fea8:c72c 13 12 False False But transfer speed is still capped to one.... Next try. Disable IPv6 on the client, force SMB to listen only to IPv4, set 192.168.178.8 as the IP of "THOTH" through the windows hosts file and reboot the client, but still no success 🙈 # SMB Conf: interfaces = "192.168.178.8;speed=1000000000" "192.168.178.9;speed=1000000000" bind interfaces only = yes netstat -lnp --wide | grep smb tcp 0 0 192.168.178.8:139 0.0.0.0:* LISTEN 31758/smbd tcp 0 0 192.168.178.9:139 0.0.0.0:* LISTEN 31758/smbd tcp 0 0 192.168.178.8:445 0.0.0.0:* LISTEN 31758/smbd tcp 0 0 192.168.178.9:445 0.0.0.0:* LISTEN 31758/smbd So do it reverse. This time IPv6 is enabled on the client, but server gets IPv6 fully disabled... Not sure if this is important, but the server resolves to the second ethernet port. Don't know why: Server and client reboot... does not work. ... after several additional tests I found out, that it is unreliable. For example if I disable IPv6 only in the router and reboot the client, then SMB Multichannel works. But only for several minutes?! Then it fails again. Next test is to disable IPv4 in the router and reboot all devices incl switches. Maybe thats the reason?!

Ok, das hat es offensichtlich nicht gebracht 😅 Dass die Fehler jetzt häufiger kommen ist aber denke ich Zufall. Die meisten im Netz empfehlen pcie_aspm=off. Das werde ich jetzt mal kurz testen, aber dauerhaft möchte ich das nicht nutzen, weil dann ja alle PCIE Geräte aktiv bleiben. Besser wäre es nur die NVMe zu anders einzustellen, wenn es das denn ist.

This was only a guess. Maybe the problem lies somewhere else?! As long nobody else has this problem and it isn't verified, it does not make sense to warn everyone. By now you are the only one who had this problem. And as I said, if it is related to the power management, it can happen all the time. Not only because of this modification. If this was your problem, then yes, but by the same argumentation Unraid would need to throw a warning if you disable Docker or if you create multiple pools or...?! PS Wait a week or so. If it does not happen again, revert your sleep setting and we will see if this was the reason. By the way: How did you disable sleep? For SATA these methods exist: max_performance medium_power med_power_with_dipm min_power Which was active in your setup?

Ich ergänze nun auch mal meins: lspci -nn | grep Host 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers [8086:3ec6] (rev 07) 00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller [8086:a36d] (rev 10) uname -a Linux thoth 5.10.28-Unraid #1 SMP Wed Apr 7 08:23:18 PDT 2021 x86_64 Intel(R) Xeon(R) E-2146G CPU @ 3.50GHz GenuineIntel GNU/Linux Ich habe aktuell nämlich selten diese Meldung (absolut zufällig, und teilweise Stunden auseinander): Aug 22 15:55:31 thoth kernel: pcieport 0000:00:1d.0: AER: Corrected error received: 0000:04:00.0 Aug 22 15:55:31 thoth kernel: nvme 0000:04:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Aug 22 15:55:31 thoth kernel: nvme 0000:04:00.0: device [15b7:5006] error status/mask=00000001/0000e000 Als BIOS verwende ich auch schon F2c. Allerdings habe ich dauerhaft tsc, auch wenn ich hpet nicht deaktiviert habe: cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc Aber wer weiß. Vielleicht wechselt er ja für eine Millisekunde auf hpt und dann wieder zurück und dadurch kommt der Fehler. Daher habe ich jetzt auch hpet=disable in die syslinux.cfg gepackt: Mal sehen ob es hilft.

Your hardware problem has nothing to do with this modification. If it is related to the power management of your SSD, it would even happen if you disable docker.

Ja, weil solange er nicht fertig ist, hast du keine gültige Parität und damit auch keine Ausfallsicherheit.

Mach mal Tools > New Config, setz aber bei Pools den Haken, dass du die behalten (Preserve) willst. Dann weist du dem Array nur Disk 1 zu, also nicht die Parity. Passt es jetzt? Denk dran, dass ein Formatieren die Disk 1 natürlich löscht. Oder waren das jetzt eh leere Disks?

Natürlich sollte man niemals eine root-fähige GUI über das Internet verfügbar machen. Meiner Ansicht nach gehört der Remote Access bei MyServers komplett abgeschafft. Unraid hatte bereits in der Vergangenheit eine Sicherheitslücke in der GUI und wer glaubt, dass das die letzte Lücke war, ist naiv. Es gibt auch seit Jahren nach wie vor den Bug, dass der Webserver abschmiert, wenn man auf einem PC die GUI offen lässt. Hatte ich erst die Tage wieder. Bestimmt lustig, wenn ein Angreifer den Grund dafür findet und weltweit Unraid Server blockiert. Als langjähriger Web-Entwickler und nach Sichtung des GUI-Quelltextes, kann ich dir auch sagen, dass kein Hoster dieser Welt so etwas ins Internet stellen würde (Shell Scripte, PHP mit aktivem exec, vollständiger Root-Zugang, etc.). Weiterhin gibt Limetech die folgenden Tipps: man soll ein komplexes Passwort nutzen man soll den öffentlichen Port "zufällig" wählen nicht mehr Ports als notwendig freischalten Dazu kommt: die MyServer Domain ist zufällig In der IT-Sicherheit nennt man sowas Security through Obscurity und das hat mit Sicherheit rein gar nichts zu tun. Schon gar nicht, wenn wie hier alle MyServer Domains und öffentlichen IPs zentral von unraid.net verwaltet werden. Die Sicherheit endet also sofort, wenn jemand den unraid.net Server von Limetech hackt. Wenn der Angreifer dann noch so clever ist und alle aus dem Forum abmeldet, um sie zur wiederholten Eingabe ihres Passworts zu zwingen (um doppelt verwendete Passwörter anzutesten) oder vielleicht einfach ein Phishing-Attacke über die MyServer Domain startet, um den Server-Zugang direkt zu erhalten, dann wird es richtig lustig. Dann hilft übrigens auch kein 2FA im Forum, denn für den Login auf dem Server braucht es das nicht. Eine ähnlich gelagerte Attacke gab es bereits bei Ubiquiti. Zuletzt sei auch angemerkt, dass es gar nichts bringt, dass die MyServer Domain zufällig ist, da durch die Port-Freigabe im Router, natürlich auch alle Zugriffe auf die öffentliche IP-Adresse des Internetanschlusses an den Unraid-Server weitergeleitet werden. Und da draußen sind tausende Bots unterwegs, die den ganzen Tag nach offenen Ports suchen, um mögliche Angriffsziele zu ermitteln. Die Tage haben Forscher zB 3,6 Millionen öffentliche erreichbare MySQL Server gefunden, wovon nicht einer öffentlich erreichbar sein sollte, weil man Datenbanken immer nur lokal nutzen sollte. Fazit: Wer unterwegs auf seine Unraid GUI zugreifen möchte, nutzt dafür bitte einen VPN und wer Backups von seinem Stick in einer Cloud haben möchte, der "baut" sich dafür bitte eine entsprechende Lösung.