DarkMan83

This is still present in Unraid 7.0 and it's sooooo annoying.....

I had Storj running for over a year now without problems at all. Since the last updates my banwidth.db got corrupted several times. It's like repairing it and storj runs like ~2 h and bandwidth.db is corrupted again. Since the last update storj-node stops on startup with info.db error. All files are in place and nothing was changed at all. -> info.db file is there... Greetings Dark

Hi there, in Unraid 6.11.x "expect" was working. In Nerdtools we already have tcl and libtcl, but "expect" is missing. Please add it back. Example usage: #!/usr/bin/expect set USER "" set HOST "x.x.x.x" set PWD "" #log_file /var/log/ssh_tmp.log set timeout 30 log_user 1 set send_slow {1 .01} send_log "Connecting to $HOST using $USER user\n" eval spawn ssh -F /boot/config/ssh/root/ssh_config -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o Connecttimeout=30 "$USER\@$HOST" expect { timeout { send_user "timeout while connecting to $HOST\n"; exit } "*No route to host*" { send_user "$HOST not reachable\n"; exit } "*assword: " { send -s $PWD\r } } expect { "*hpiLO->" { send "fan pid 33 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 34 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 35 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 36 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 37 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 38 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 42 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 52 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 53 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 54 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 55 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 56 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 57 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 58 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 59 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 60 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 61 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 62 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 63 lo 5600\r" } } expect { "*hpiLO->" { send "fan pid 33 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 34 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 35 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 36 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 37 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 38 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 42 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 52 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 53 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 54 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 55 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 56 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 57 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 58 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 59 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 60 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 61 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 62 hi 9500\r" } } expect { "*hpiLO->" { send "fan pid 63 hi 9500\r" } } expect { "*hpiLO->" { send "exit\r" } } send_user "Disconnected\n" close Greetings Dark

Hi, auch wenn der Thread hier schon alt ist, ich hab die ganze Thematik auch gerade nochmal durch. Ich hatte auch HLS-Proxy probiert, da komme ich dann aber auch ohne Ton raus. Meine entgültige Lösung ist nun: Telerising (FFMPEG Flag für Playlist gesetzt) -> TVHeadend -> Antennas -> Plex In dieser Konstellation lüppt es, ich konnte keine Probleme mit Zatto bezüglich stoppen von Plex feststellen. Ich hatte es erst mit xTeve probiert, dort hat es aber nicht gefunkt, wegen benötigtem Login bei TVHeadend. TVHProxy hat bei mir leider Parsefehler rausgehauen, deshalb auch nicht nutzbar. Anmerkung: TVHeadend zeigt bei allen Muxes einen Fehler an, dadurch hat das Zuweisen der Services ewig gedauert, da das immer wieder gemacht werden muss, bis alle 160 Muxes zugeordnet sind. Laufen tuts dann trotz angezeigtem Fehler. Die Umschaltzeiten sind aber halt fragwürdig, bei mir so 10 sek, kann aber auch an meinem alten Server mit DDR3 usw. liegen oder aber an der FFMPEG Pipe. Telerising von "qoopido/telerising.minimal" wurde von Dockerhub benutzt. TVHeadend von Linuxserver. Vorteil wäre nun halt noch, dass ich bei GitHub z.B. noch einen PlutoTV Parser gesehen habe, der eine M3U erstellt, die könnte man dann auch noch in TVHeadend importen ^^ Gruß Dark

Ich hab nun die shadow und die smbpasswd gelöscht und nun bietet er mir auch an ein Passwort zusetzen... Da sind wohl paar Seiten im Wiki, die nimmer aktuell sind...

Bevor ich den Server runtergefahren habe, waren die Passworthashes noch in der Shadow Datei drinne. Nach dem tausch der Nertzwerkkarte und wieder Hochfahren kam ich nimmer rein, deshalb hab ich den USB-Stick mal am PC nachgeschaut und in der Shadow war der root dann ohne pw-hash.

Ich hab heute ne andere Netzwerkkarte eingebaut, wegen SFP+ und 10 GIG und so... Lange rede kurzer Sinn... Unraid hatte nun kurzzeitig ne andere IP und / oder weil die Netzwerkkarte gewechselt hat, meinte Unraid alle passwörter zu resetten. Nun komm ich nicht mehr ins Webinterface und auch nicht per SSH rein... Wenn ich nach dem WIKI gehe, dann soll das default passwort für root ja "empty" also leer sein, leider erlaubt die loginseite von Unraid kein leeres Passwortfeld Hab ich irgendwas übersehen? P.S. Das einzige, was ich nun noch nicht gemacht habe, ist alle Passwort Dateien löschen, die in /boot/config/ liegen... Ich hatte mich halt nur gefragt, ob dann das Wiki noch aktuell ist, wenn man so gar nicht mehr rein kommt, ohne die Dateien zu Löschen. Gruß Dark

Ich meine irgendwo gelesen zu haben, dass bei einem ARGO-Tunnel immer gecached wird, unabhängig von der Einstellung in Cloudflare. Frag mich aber nicht wo... Auf jeden Fall bin ich halt gesperrt. Und deshalb nutz ich den ARGO-Tunnel nicht mehr, nur für ne Portfreigabe, da wird nix durch schneller, im Gegenteil... Über den ARGO-Tunnel lief bei mir alles langsamer. Und da ich z.B. Plex sowieso über ne Subdomain und mit "cache off" laufen habe, keine Probleme 🙂 Gruß Dark

Ich kann dir da leider nicht helfen, mein Argo-Tunnel wurde gesperrt, da Cloudflare nur HTTP/HTTPS traffic untersützt und man für Videostreaming separat bezahlen soll... Gruß Dark

Könnte sein, dass das bei dir nicht funzt, weil du den swag CF Mod nicht installiert hast? und bei mir benutze ich die Hauptdomain nicht, weil ich noch einen normalen Server im rechenzentrum habe. Die Konfiguration hab ich bei mir auf jeden Fall laufen, wichtig ist bei SWAG das Zertifikat als wildcard erstellen zu lassen, dann funktioniert es auch. damit das Zertifikat in SWAG dann für *.deinedomain.de gilt, sonst akzeptiert der die anderen Subdomains nicht. aber wenn deine config für dich so okay ist, ist ja alles gut. Gruß Dark

du machst eine Subdomain mit einem CNAME und kannst dann beliebig viele Subdomains per CNAME als Alias erstellen und als Ziel die erste Subdomain benutzen. deshalb ja in Cloudflared *.deinedomain.de und in SWAG wildcard. Also in CF z.B. erste Subdomain: CNAME cloud und Ziel der ARGO Tunnel. Subdomain 2: CNAME plex und Ziel cloud.deinedomain.de P.S. Bitte bedenkt, dass wir SWAG sozusagen als firewall benutzen, da wir hier einen VPN Tunnel aufbauen, geht der traffic vorbei an der Firewall in eurem router und direkt zum server. Glücklicherweise hat CF ja eine Firewall, dort hab ich z.B. diverse Länder geblockt und auch immer den Botfight modus an! Wollte ich nur mal gesagt haben. Gruß Dark

ich habe in CloudFlare keine extra Zertifikate hinterlegt, nur das generelle aktiviert. Ich sage ja nicht, dass mein Weg der richtige ist, aber es funktioniert alles. Wenn es anders und beste Wege gibt, klärt mich gerne auf, bin für beste Lösungen offen.

klar, wird alles geforwarded und als Verifizierung nehme ich ja Verifizierung über DNS und damit geht er über die CloudFlare API und das läuft nicht über den Tunnel kennt swag ja nicht... wenn man auf die Domain kommt, steht da eh das CF Zertifikat, also wayne... aber cloudflared leitet die Domain an swag weiter und damit kann swag sein eigenes Zertifikat für die Domain checken. Bei mir funktioniert es zumindest alles, siehe auch Screenshot für swag config. Nochmal angemerkt: Wenn man in swag Verifizierung über DNS (CF) am hat, dann braucht man keinen offenen Port 80 o.a., da alles per CF API gemacht wird.

du brauchst eigentlich kein Zertifikat in CloudFlare erstellen und in nginx registrieren, wenn du swag benutzt, dort werden automatisch Zertifikate erstellt... Aber mach dir du meinst 😁

Hab mich da auch an das Video von Ibracorp gehalten und lasse mein Plex über swag laufen... Cloudflare -> Cloudflared -> Swag -> Plex In Plex Fernzugriff deaktivieren und unter Netzwerk dann die url z.B. https://plex.deinedomain.de:443 eintragen. Im Router alle Portfreigaben deaktivieren, werden nicht mehr benötigt -> Ich lass alle Webanwendungen über den Argo-Tunnel laufen, dementsprechen hab ich kein Port 80 + 443 mehr offen, da alles dann über Cloudflared kommt und dann durch SWAG an den richtigen Docker geht. Zusätzlich ist der Vorteil, dass nun alles erst bei CF durch die Firewall muss. Die Rule bei Cloudflared sieht bei mir z.B. so aus: # forward all traffic to Reverse Proxy w/ SSL ingress: - service: https://192.168.1.25:443 originRequest: originServerName: "*.deinedomain.de" SWAG-Config: Die SSL-Einstellung bei CF sieht bei mir so aus: Ich habe heute einen Stream getestet und das sieht man auch an den verarbeiteten Daten -> 5 GB Wenn du die Weboberfläche deines Plex auch über die Subdomain erreichen möchtest, dann musst du bei Cloudflare noch im Dashboard unter Regeln eine Ausnahme für deine Plex-Subdomain einrichten und den Rocket-Loader deaktivieren. Gruß Dark

Ich hebe bei mir gar keine Portfreigaben mehr eingerichtet, läuft alles über CF Argo Tunnel und da muss der gesamte traffic ja darüber gehen... Sonst könnte man ja von extern nix auf plex schauen. Und das dashboard zeigte auch so 20GB nach einem Film an. Gruß Dark

Host access is disabled and no container rely on any other and each restart other Containers are online, so it seems to be random...

Does anyone still have the docker problem after reboot/cold boot? each time only some dockers started (random and regardless of bridged or br0 etc.) after reboot and i have to disable and reenable the docker service?

Does this only apply to the 410i? I've a gen 8 with a 420i and could run the drives normally with SAT or hp cciss driver, no problems at all... Is the 410i so much different thannthe others?

Is this still worked on? How to set driver to use for sensors? I have to use the LAN_2_0 instead of LAN....