Asgard

Hi @54lzy I had a similar problem. My Solution is described in detail the German forum: https://forums.unraid.net/topic/125268-ipv4-ds-lite/#findComment-1579293 Basically solution was: Step 1: Change Wireguard to use IPv6 AllowedIPs = 192.168.178.0/24, ::/0 Endpoint = [7zPulbicAdress3y5n.myfritz.net]:56769 Step 2: Make sure SMB listens to IPv6 Interface as well: Settings → Network Services → SMB → Extra configuration bind interfaces only = no Step 3: Use different Port then 445 for SMB Settings → Network Services → SMB → Extra configuration smb ports = 1445 Then restart samba service: /etc/rc.d/rc.samba restart Usage: smbclient -L //192.168.178.10 -p 1445 -U username -W Workgroup or in Linux File Browser like Nemo: smb://192.168.178.10:1445/

Nicht zu 100% sicher...habe alles geprüft was mir Eingefallen ist. Automatische Portfreigaben für den Unraid Server in der FritzBox, keine IPTables Firewall Blockaden am Unraid, Share Zugriff lokal vor Ort funktioniert und SMB Port lief auch am Unraid Server und war für IPv4 und IPv6 für alle Hosts freigeschaltet: ss -tulpen | grep 445 tcp LISTEN 0 50 127.0.0.1:445 0.0.0.0:* users:(("smbd",pid=3712146,fd=29)) ino:103676453 sk:1010 cgroup:/ <-> tcp LISTEN 0 50 192.168.178.10:445 0.0.0.0:* users:(("smbd",pid=3712146,fd=31)) ino:103676455 sk:1018 cgroup:/ <-> Andere Ports wie SSH haben nach der Umstellung auf IPv6 in Wireguard auch funktioniert...wüsste nicht wer mir sonst den 445 blocken würde.

@Cornflake Ich habe kürzlich meinen Unraid Server von der Wohnung A mit dem ISP Telekom in eine andere Wohnung B mit 1&1 als ISP umgezogen. In der Wohnung B habe ich dann wie bisher auch, eine Wireguard VPN Verbindung über die Fritzbox eingerichtet, um von extern Zugriff auf den Unraid Server und die Shares zu erhalten... Ausgangssituation:Wireguard VPN zur FritzBox funktionierte, ich kam auf die Weboberfläche von Unraid per IP drauf und auch auf die HTTP/S Urls von Docker Diensten wie z.b. Paperless-ngx. Was jedoch nicht funktionierte war der Zugriff auf die Shares. Zudem hatte ich ein merkwürdiges Verhalten mit Verbindungsabbrüchen bei Docker & Application Updates (timeouts), die ich mir nicht erklären konnte. SSH Tunnel auf Port 22 ging auch nicht mehr etc...irgendwie war der Wurm drin und ich wusste, dass ich am Unraid selbst nichts geändert habe. Analyse:In der Wohnung B wird in der FritzBox 7590 unter Internet --> Online-Monitor --> Verbindungsdetails wird angezeigt, dass die Verbindung Internet, IPv4 --> verbunden seit xxx Uhr, 1&1 Telecom GmbH FRITZ!Box verwendet einen DS-Lite-Tunnel Dank Infos wie https://persoft.de/tipps-tricks/wireguard-vpn-server-auf-fritzboxen-am-ds-lite-anschluss/ https://fritz.com/service/wissensdatenbank/dok/FRITZ-Box-7490/1497_Kann-MyFRITZ-an-einem-Internetzugang-mit-IPv6-DS-Lite-genutzt-werden/ konnte ich das dann besser verstehen was das Problem war. Hauptproblem: Beim DS-Lite-Tunnel gibt's Schwierigkeiten bei der "geteilten" IPv4 Adresse und den Default Portfreigaben. Zudem hat anscheinend 1&1 den Port 445 für die Shares blockiert. Funktionierende Lösung:Schritt 1) IPv6 für die Wireguard Verbindung verwenden:Zunächst prüfen ob der FritzBox Zugang unter https://www.myfritz.net/devices/#/ auch IPv6 Adresse anzeigt. Anschließend in der Wireguard Client Config, sicherstellen, dass auch die IPv6 von der fritz box verwendet wird --> öffentliche Fritzbox url mit eckigen Klammern [ ] schreiben und die IPv6-Range in den AllowesIPs ergänzen ``` [Peer] AllowedIPs = 192.168.178.0/24, ::/0 Endpoint = [7p6kyÖffentlicheAdresse3y5n.myfritz.net]:56769 ``` ::/0 heißt: alles IPv6 durch den Tunnel, kann man wenn's funktioniert weiter einschränken auf die IPv6 range Neu ins VPN einwählen und dann prüfen mittels: dig AAAA 7p6kyÖffentlicheAdresse3y5n.myfritz.net sollte mit der öffentlich IPv6 Adresse antworten (z.b. AAAA 2001:16b8... ==> huhuu, SSH Zugriff geht wieder ;-) Schritt 2) Unraid SMB IPv6 Interface freischaltenAm Unraid Server unter Settings → Network Services → SMB → Extra configuration das IPv6 Interface freischalten: # Alle Interfaces erlauben (z.b. IPv6 Wireguard Verbindungen über Fritzbox): bind interfaces only = no Schritt 3) Alternativer SMB Port wegen ISP 1&1Anscheinend wird beim DS-Lite-Tunnel vom ISP 1&1 der Standart SMB Port per default 445 blockiert... daher auch Settings → Network Services → SMB → Extra configuration den smb Port auf einen anderen verlegen, z.b.: smb ports = 1445 Anschließend einmal in Unraid ins Terminal gehen und den Samba Dienst neustarten: /etc/rc.d/rc.samba restart ggf gegencheck ob die Portfreischaltung geklappt hat: telnet 192.168.178.10 445 Danach funktioniert der Zugriff auf die Shares wieder: smbclient -L //192.168.178.10 -p 1445 -U username -W Workgroup bzw über Nemo: smb://192.168.178.10:1445/ Ich hoffe das kann dem ein oder anderen hier helfen, der in der selben bescheidenen DS-Lite-Tunnel Situation ist :-)

Danke @Sky-Dragon Ich hab mittlerweile meinen Workflow etwas optimiert, um die die Dokumente automatisch vom Scanner zum Paperless-ngx zu bekommen. Ich besitze einen Epson XP-7100 Drucker der leider keine Möglichkeit bietet die gescannten Dokumente direkt auf ein Unraid Share abzulegen. Um trotzdem in den Genuss zu kommen, dass die eingescannten Dokumente automatisch von Papless konsumiert werden bin ich wie folgt vorgegangen: Anleitung: Automatisch gescannte Dokumente über Unraid User Scripts zu Paperless verschieben Vorbereitungen: 1.) In den Druckereinstellungen eine Freigabe erstellt um auf den USB-Stick vom Scanner zugreifen zu können: 2.) Mit dem im Drucker hinterlegten Credentials lässt sich dann auf alle eingescannten Dokumente über smb zugreifen. Bisher hatte ich diese immer manuell in den Paperless-NGX consume Ordner kopiert. Jetzt kamen die folgenden Optimierungen dazu. 3) Tätigkeiten im Unraid: Unter Settings--> User Scripts ein neues User Script angelegt. Mein Script prüft ob ein neues gescanntes Dokument mit dem Namen "EPSON001.PDF" auf dem USB-Storage vom Epson vorhanden ist. Falls dem so ist, kopiert es alle gescannten Dateien über den smbclient vom USB-Storage in den "consume" Ordner vom Paperless-NGX #!/bin/bash # This script is an automation for paperless-ngx. # It copys all scanned files from the USB plugged into the Epson XP 7100 printer # to the consume folder from paperless-ngx # Afterwards all pdf files that have been copied are deleted CREDENTIAL_FILE=/boot/config/asgardscripts/epsonpass.txt CHECKFILENAME=EPSON001.PDF # Check if new scanned file EPSON001.PDF is available on epson usb storage if smbclient -A ${CREDENTIAL_FILE} //192.168.178.34/usbstorage/ -D EPSCAN/001/ -c "ls \"${CHECKFILENAME}\"" > /dev/null 2>&1 then echo "There are new SCANNED documents for paperless available" echo "Copy all scanned files to paperless consume folder" smbclient -A ${CREDENTIAL_FILE} //192.168.178.34/usbstorage/ -D EPSCAN/001/ -c 'prompt OFF;recurse ON; lcd "/mnt/user/dokumente_paperless/consume/"; mget *' echo "Cleanup by deleting all scanned '*PDF' to scanned documents from EpsonXP7100 ": smbclient -A ${CREDENTIAL_FILE} //192.168.178.34/usbstorage/ -D EPSCAN/001/ -c 'prompt OFF;recurse ON; del "*.PDF"' else echo "There are no documents to consume" fi exit 0 Die epsonpass.txt habe ich manuell auf dem Unraid USB Stick angelegt root@Asgard:/boot/config# mkdir asgardscripts root@Asgard:/boot/config# cd asgardscripts/ root@Asgard:/boot/config/asgardscripts# touch epsonpass.txt root@Asgard:/boot/config/asgardscripts# nano epsonpass.txt und dann wie folgt editiert: username=epson password=eingestelltespassword domain=WORKGROUP 4) Anschließend in den User-Scripts die Häufigkeit einstellen in dem das Script ausgeführt und die Dokumente vom Scanner abholen soll. Voilà, fertig ist der neue automatische Workflow 🙂 PS: Ursprünglich wollte ich mittels rclone machen wie es im Sempervideo schön erklört wurde Aber irgendwie hat rclone bei mir mit der Freigabe vom Drucker nicht funktioniert und ich hab die Fehlermeldung "error couldn't connect SMB: invalid response error: invalid negotiate flags" nicht lösen können und bin daher auf smbclient umgestiegen.

@Sky-Dragon Danke für die Strukturierungsinfos. Die Tipps haben mir sehr geholfen. Ich mache die Gruppenzuordnung anders, damit ich meine bestehende Dokumenten-Ordnerstruktur beibehalten kann. Ich mache diese nicht über den Korrespondenten via "0_GRUPPENNAME", sondern lege eigene Speicherpfade für bestimmte Korrespondenten in Paperless an. Ich hab per Default im Unraid Container den Speicherpfad wie folgt definiert: PAPERLESS_FILENAME_FORMAT={created_year}/{correspondent}/{created}-{document_type}-{title}-{tag_list} und bei Themenbereichen die Gruppieren möchte, verwende ich eigene Speicherpfade. Beispiel: Ergibt dann abgelegt: Über die Filterfunktion im Papleress kann ich mir dann alle Dokumente zu einem bestimmten Speicherpfad anzeigen lassen und bekomme damit z.b. direkt alle Versicherungen oder Handwerker Dokumente angezeigt und kann diese dann weiter Filter nach Tags wie "Beleg Einkommensteuererklärung 2023" Ich bin mir noch nicht ganz sicher, aber ich denke das ist langfristig so effizienter, da ich dann auch nach bestimmten Handwerkern (Korrenspondenten) weiter filtern kann. Wenn ich nur eine Korrespondentengruppe mit "0_Handwerker" habe, wird es später schwierig wenn ich zwischen Handwerker A und Handwerker B filtern möchte. Rückfrage1: Zudem ermöglichen mir die Speicherpfade eine Trennung zwischen privaten Dokumenten und gewerblichen Dokumenten für Gewerbe1, Gewerbe2 zu erreichen. Oder würdet ihr eher eine Trennung zwischen privat und Gewerbe über unterschiedliche User im Paperless handhaben? Rückfrage2: Wie macht ihr es, wenn ihr z.b. eine Handwerkerrechnung die dazugehörige Quittiung / Überweisungsbeleg verknüpfen möchtest? Zusatzinfos: @Sky-Dragon Hast du das mit dem PAPERLESS_TRASH_DIR bei dir getestet? Ich hatte damit anfangs Probleme, weil diese Variable per default nicht befüllt ist und er beim Klick auf "Dokument löschen" das Dokument nicht in den PAPERLESS_TRASH_DIR Pfad verschiebt. Lösung dazu habe ich hier auf englisch dokumentiert:

Thank you very much for that hint! Additionally I want to mention, that the trash folder /usr/src/paperless/media/trash did not exist on my paperless instance. Therefore I created the folder by opening the console: and added the folder with: root@ab2ac556cb92:/usr/src/paperless/src# cd ../media/ root@ab2ac556cb92:/usr/src/paperless/media# mkdir trash root@ab2ac556cb92:/usr/src/paperless/media# chown paperless trash/ root@ab2ac556cb92:/usr/src/paperless/media# chgrp paperless trash/ Then I followed your hint and created the Variable for PAPERLESS_TRASH_DIR to point to that newly created trash folder and map that internal trash folder to path on my smb share so I have write access and can delete the files in the trash folder by myself or periodically via user script. Thank you again for sharing.

Thank you @startsomewhere & @g1an7 I was able to solve the issue with your help by switching back from lscr.io/linuxserver/nextcloud:latest to lscr.io/linuxserver/nextcloud:25.0.2 After booting up, nexcloud was in maintenance mode and I could apply the ooc upgrade command to upgrade all plugins. As you can see, without switching back to nextcloud:25.0.2 I was not able to get into maintenance mode before, cause of the "This version of Nextcloud is not compatible with > PHP 8.0," Error Message Thank you very much for sharing this solution.

Interessant fand ich, dass ich diese Probleme mit der Android App von JellyFin nicht hatte. Da kann ich den Container beliebig verändern und neu starten ohne das es zum obigen Fehlerbild kommt. Das Neustarten vom JellyFin Container (mit neuen Library Path) geht bei mir so schnell, dass bei meinen Kindern am Tablet nicht mal der Stream unterbrochen wird.

Danke @ich777 Ich hatte das gleiche Problem wie @oberolmer mit dem JellyFin Container von lscr.io/linuxserver/jellyfin:latest und kann bestätigen, dass deine Lösung funktioniert hat. Fehlerbild: Lässt sich wie folgt reproduzieren: 1) Melde dich z.b. als Admin in der Jellyfin Weboberfläche an: http://192.deineUnraidIP:8096/web/index.html#!/home.html 2) Verändere anschließend im Unraid unter Docker eine beliebige Einstellung für den JellyFin Container, z.b. füge einen einen neuen Library Path zum Container hinzu: 3) Bestätige mit "Apply" die Änderung, so dass der Container neu erstellt wird: 4) Drücke dann im Browser F5 für einen Refresh y voilá Alternativ neuen Browsertap und mit dem DNS Namen anstelle der IP JellyFin aufrufen http://deinunraidname:8096/web/index.html#!/home.html Lösung: Lösche mit STR+Shift+Entf im Browser den Browsercache! Anschließend solltest du wieder normal im JellyFin anmelden können:

@susa Für meinen Workaround hab ich damals einfach unter "Shares" die Freigabe umbenannt: Das Problem ist bei mir mit neueren Unraid Versionen (hier 6.11.3) bisher nicht mehr aufgetreten.

Hi @susa ich hatte das Problem jetzt auch ein paar mal mit Unraid 6.11.0. Ich konnte es mir aber nicht erklären und es hat auch nur zwei Freigaben betroffen. Habe als temporären Workaround kurz die Freigabe umbenannt und dann konnte ich weiterarbeiten ohne neustart. Würde mich interessieren, wenn es hierzu neue Erkenntnisse gibt.

In case you search for default user to login: user: admin pass: admin I did not find this mentioned somewhere. You can then change the password for the admin user in the user management:

Hi @Torsten ich bin über deinen Beitrag gestolpert und hatte bis eben dasselbe Problem und auch meinen Fehler gefunden. Im Prinzip hat sich nicht gegenüber dem Video von @SpaceInvaderOne mit Unraid v.6.9.2 nicht viel geändert. Der Unterschied bei Unraid 6.9.2 ist die Stelle bei min 3:28, wo gezeigt wird das Unraid ein Keyfile nach Eingabe der Passphrase in der Unraid GUI unter /root/keyfile ablegt. Dies ist bei Unraid 6.9.2 nicht der Fall, der Mechanismus funktioniert aber weiterhin. Grundsätzlichen Vorgehen bei Unraid 6.9.2 beim Automount von einem encrypted array: Schritt 1: Auf den Unraid Server per SSH verbinden: ssh [email protected] Schritt 2: Passphrase in Plaintext im Keyfile auf dem USB Stick ablegen: echo -n 'my$1cureArray!Password' > /boot/config/keyfile_tower Schritt 3: Unraid Go Script mit bearbeiten cat /boot/config/go #!/bin/bash # automount cp /boot/config/keyfile_tower /root/keyfile # auto powersavings powertop --auto-tune # Start the Management Utility /usr/local/sbin/emhttp & Schritt 4: Autostart vom Array in Unraid GUI aktivieren: Schritt 5: Reboot und über encrypted Autostart freuen Anmerkungen zu Schritt 2: Keyfile Hier lag mein Fehler. Ich hatte dummerweise nicht einfache Hochkomma ' ' sondern doppelte " " verwendet. Damit werden die Shell Befehle interpretiert und ausgeführt. Sieht dann beispielsweise so aus: root@tower:~# date Wed Feb 16 07:24:04 CET 2022 root@tower:~# echo -n "my$1cureArray!!" > /boot/config/keyfile_tower echo -n "my$1cureArraydate" > /boot/config/keyfile_tower root@tower:~# cat /boot/config/keyfile_tower mycureArraydate Hier habe ich im Beispiel zwei !! im Passwordstring, die dann interpretiert werden. !! führt den letzten in der Shell eingegebenen Befehl nochmal aus, in diesem Fall ist dies Befehl date Also immer prüfen ob auch das der richtige passwortstring im keyfile drin steht! Zudem gilt zu beachten: Wenn du dein Passwort mit einem Editor in dein keyfile reinschreibst, achte darauf, dass du keinen Zeilenumbruch oder eine zweite Zeile drin stehen hast. Das gibt einen anderen Byteabfolge und folglich kommt dann zurecht im Unraid die Meldung, das es sich um den falschen key handelt. Aus dem Forum entnehmen wir zudem, dass die maximale Länge für den Passwortstring 512 bytes (characters) beträgt. Quelle: Anmerkungen zu Schritt 3: Go File Der Automount muss im Go File stattfinden, bevor die Unraid GUI gestartet wird! Reihenfolge ist hier wichtig #!/bin/bash # automount cp /boot/config/keyfile_tower /root/keyfile # Start the Management Utility /usr/local/sbin/emhttp & Machst du's anders rum, wird zuerst die Unraid Gui gestartet, findet kein keyfile und der autostart des arrays funkioniert entsprechend nicht. Das war mir anfangs nicht bewusst. Anmerkungen zu Sicherheit: Hier der Anleitung habe ich bewusst auf komplizierte Schritte, wie das Auslagern des Keys auf einem WebServer, FTP, Phone, Fritzbox Share sowie das Verschlüsseln des im Plaintext gespeicherten Keyfiles ausgelassen. Ich rate jedem an, sein keyfile zu verschlüsseln, bevor ihr es über eine ggf unsichere Leitung übertragt. Wer schonmal mit Wireshark oder anderen Netzwerksniffern gearbeitet hat, weiß was ich meine. Recht gute Ansätze dazu werden hier z.b. mit 7z beschrieben:

@i-B4se Danke für die Einschätzung. Vielleicht sollten wir mal einen gesonderten Thread zu dem AsRock Board aufmachen. Die BIOS-Optionen für die AMD CPU sind mir dezent zu umfangreich und bei AsRock irgendwie schlecht dokumentiert. Toll wäre, wenn man IPMI auch temporär komplett ausschalten könnte. Aktuell brauche ich die Leistung der CPU noch nicht und hatte überlegt ob ich die nicht via Undervolting sogar ein bisschen runtertakte....hab mich dann aber nicht getraut, da gerade alles stabil läuft...wenn dann demnächst die PV-Anlage installiert wird tut der Stromverbrauch tagsüber auch nicht mehr so dolle weh wie jetzt. Aktuell laufen meine CPU Kerne fast dauerhaft im C3 mit 1400Hz: # cpufreq-info | grep "stats" cpufreq stats: 3.80 GHz:0.02%, 1.70 GHz:0.06%, 1.40 GHz:99.92% (1490) cpufreq stats: 3.80 GHz:0.05%, 1.70 GHz:0.03%, 1.40 GHz:99.91% (1174) cpufreq stats: 3.80 GHz:0.06%, 1.70 GHz:0.06%, 1.40 GHz:99.89% (1063) cpufreq stats: 3.80 GHz:0.06%, 1.70 GHz:0.03%, 1.40 GHz:99.91% (1145) cpufreq stats: 3.80 GHz:0.06%, 1.70 GHz:0.03%, 1.40 GHz:99.91% (866) cpufreq stats: 3.80 GHz:0.06%, 1.70 GHz:0.04%, 1.40 GHz:99.90% (847) cpufreq stats: 3.80 GHz:0.04%, 1.70 GHz:0.04%, 1.40 GHz:99.92% (719) cpufreq stats: 3.80 GHz:0.05%, 1.70 GHz:0.06%, 1.40 GHz:99.89% (881) cpufreq stats: 3.80 GHz:0.01%, 1.70 GHz:0.03%, 1.40 GHz:99.95% (507) cpufreq stats: 3.80 GHz:0.06%, 1.70 GHz:0.02%, 1.40 GHz:99.92% (602) cpufreq stats: 3.80 GHz:0.07%, 1.70 GHz:0.04%, 1.40 GHz:99.89% (562) cpufreq stats: 3.80 GHz:0.08%, 1.70 GHz:0.05%, 1.40 GHz:99.87% (430) cpufreq stats: 3.80 GHz:0.03%, 1.70 GHz:0.04%, 1.40 GHz:99.92% (600) cpufreq stats: 3.80 GHz:0.03%, 1.70 GHz:0.03%, 1.40 GHz:99.94% (792) cpufreq stats: 3.80 GHz:0.05%, 1.70 GHz:0.06%, 1.40 GHz:99.89% (802) cpufreq stats: 3.80 GHz:0.05%, 1.70 GHz:0.04%, 1.40 GHz:99.92% (558)

Könnten wir JellyFin noch mitkämpfen lassen? Ich hatte am QNAP immer nur Plex und hab mit Kodi (installiert auf Xiami Mi TV Box) auf DLNA Server zugegriffen....bis dann nach ein paar Jahren die Lizenz ausgelaufen ist und schwubs im QNAP Plex nicht mehr zur Verfügung stand. Mit Unraid stehen mir neue Möglichkeiten offen und ich habe gerade angefangen mich mit Plex, Emby & JellyFin zu beschäftigen...Suche genau sowas, wo ich die Sachen die die Kids schauen dürfen mit sauber steuern kann.