SidM

Great! Thank you so much! It's working again!

Good evening! I have Nextcloud version 31.0.4 installed and am having trouble displaying images taken with an iPhone and iOS 18. Is there a solution? I read that libheif needs to be updated to version 1.18.0. But I also read something about Alpine being updated to 3.21 as the underlying framework, which should automatically have the latest version of libheif. Can anyone help me see my pictures in Nextcloud again? Thanks!

So, after endless attempts, I finally got it done. For everyone who also wants to use the script in connection with the rsync server, the lines must look like this: # user-defined rsync command alias rsync='rsync -e "ssh -p5020 -o StrictHostKeyChecking=no"' # user-defined ssh command alias ssh='ssh -p5020 -o StrictHostKeyChecking=no' I have chosen port 5020 as an example.

So, nach endlosen Versuchen habe ich nun es endlich hinbekommen. Für alle die auch das Script in Verbindung mit den rsync-Server nutzen wollen, so müssen die Zeilen aussehen: # user-defined rsync command alias rsync='rsync -e "ssh -p5020 -o StrictHostKeyChecking=no"' # user-defined ssh command alias ssh='ssh -p5020 -o StrictHostKeyChecking=no' Ich habe hier als Beispiel Port 5020 gewählt.

Hallo zusammen, ich möchte hier noch einmal nachfragen wie ich das Skript zusammen mit dem rsync Container zum laufen bringen kann. - ich habe das Script auf dem Ziel Server in der Version 1.7 - Auf dem Quell Server ist der rsync Container mit Port 5020 im Bridge Modus eingerichtet - der SSH_AUTH_KEY_1: ist vom Ziel Sever eingetragen - im script ist folgendes als Quell und Zieladresse eingetragen: "[email protected]:/mnt/user/backup2/" "/mnt/user/backup" - in der Zeile 93 habe ich #alias ssh='sshpass -p "<password>" ssh -o "StrictHostKeyChecking no"' ersetzt durch: alias ssh='ssh -p 5020' wenn ich jetzt das script starte bekomme ich die folgende Meldung: Script location: /tmp/user.scripts/tmpScripts/rsync-incremental-backup/script Note that closing this window will abort the execution of this script # ##################################### created directory /mnt/user/backup/link_dest >f+++++++++ empty.file removed '/tmp/_tmp_user.scripts_tmpScripts_rsync-incremental-backup_script/empty.file' *deleting link_dest/empty.file *deleting link_dest/ Create full backup from [email protected]:/mnt/user/backup2 to /mnt/user/backup/20241130_083115 rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(231) [Receiver=3.2.7] File count of rsync is 0 Error: Host key verification failed. rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(231) [Receiver 3.2.7] (255)! # ##################################### Clean up outdated backups Wenn ich aber in der Kommandozeile vom Zielserver folgenden Befehl eingebe, überträgt er die Dateien: rsync --itemize-changes --recursive --rsh='ssh -p5020' [email protected]:/mnt/user/backup2/ /mnt/user/backup Was ist an meiner Konfiguration falsch? Hier nutzt ja gefühlt jeder 2te das Script von @mgutt, aber ich bin irgendwie zu Blöd dafür🤷‍♂️

Servus! Da du eine Ausgabe auf einen Monitor mit den Raspberry Pi hast, geh ich von einer Installation mit aktivierten Desktop aus und nicht Headless? Mir fallen 2 Lösungen hierzu ein: Nummer 1 --> Eine VM mit z.B Linux aufsetzen und Grafikkarte durchreichen, unter diesen Linux dann IoBroker installieren. -->verbraucht unnötig Systemressourcen Nummer 2--> Den IoBroker Container nutzen --> bietet keine direkte Grafikausgabe (Nummer 3) --> wie Nummer 2 und für die gelegentliche Nutzung der VIS zusätzlich eine Linux VM installieren mit GPU Passtrough, dies kann dann über ein Browser die VIS öffnen (nicht wirklich Praktikabel) Dies setzt aber auch voraus, dass du mindestens eine intel iGPU hast oder 2 GPU's, da sich Unraid schon eine GPU "krallt". Spricht etwas gegen ein Tablet, Echo Show etc. für VIS?

Ich weiß nicht welche Änderung konkret für mich mit diesen Update zutrifft, ich schätze aber dies "fix routing when "host access" is enabled" Ich hab das Update auf 6.12.13 gemacht, aber das Problem bleibt... edit: Hab jetzt noch die Netzwerkbrücke aktiviert und nun geht sowohl ping als auch tracert. Cool, damit habe ist jetzt meine Nextcloud unter IPv4 und IPv6 erreichbar egal aus welchen Netz! Danke @alturismo und @MAM59 🍻 Für mich noch zum Verständnis: Das heißt, dass durch die Konstellation Version 6.12.6 + aktivierten Hostzugang + deaktivierter Netzwerkbrücke, es über eine VM unter Unraid nie funktionieren konnte. Wenn ich den Test im lokalen Netz aber mit einem anderen Clienten/Rechner als Unraid durchgeführt hätte, hätte es auch ohne das Update und Umstellung funktioniert?

Ich glaube den Fehler gefunden zu haben: Ich nutze Macvlan da ich als Router eine Fritzbox habe. Unter Docker ist "Host-Zugang zu benutzerdefinierten Netzwerken" aktiviert und in den Netzwerkeinstellungen "Netzwerkbrückung aktivieren" auf Nein eingestellt. So wird es auch hier beschrieben. Ich bin auf der Version 6.12.6 In der Fritzbox Netzwerkgeräteübersicht habe ich 2 Einträge von Unraid aber mit unterschiedlicher Macadresse. Beide verweisen auf die gleiche IPv4. Nun ist es auch so, dass ebenso beide Macadressen auf die gleiche IPv6 verweisen und das wird vermutlich der Knackpunkt sein? Der AAAA Record weist auf die korrekte IP hin aber die Fritzbox weiß nun nicht, wenn die Anfrage kommt, auf welche Macadresse der Traffic landen soll. Denn wenn ich den AAAA Record wieder über die Fritz aktualisieren lasse und dann wieder mit ping -6 oder tracert -6 teste, kommen antworten und die Ablaufverfolgung von tracert wird erfolgreich beendet. (local 1 Hop, extern 14 Hops)

Ping von Unraid zu NPM ? Ähm ja das funktioniert, was aber verwunderlich wäre, da Unraid und NPM die gleiche IP haben (Hostmode)

Lokal: C:\Users\SidM>tracert -6 meineDomain.de Routenverfolgung zu meineDomain.de [2a00:1f:4d40:xxxx:b62e:99ff:fea8:abb5] über maximal 30 Hops: 1 Zielhost nicht erreichbar. Ablaufverfolgung beendet. Extern: C:\Users\pierr>tracert -6 MeineDomain.de Der Zielname MeineDomain.de konnte nicht aufgelöst werden. Das hatte ich vorher schon mal probiert. Für mich klingt das nach einen DNS Problem. Der AAAA Record verweist aber auf die korrekte IPv6 von Unraid bzw. NPM. Wobei dies auf den externen zugriff zutritt, lokal aber noch etwas anderes sein muss, da ich hier über die direkte Eingabe der IPv6 erst gar nicht auf den NPM komme.

Hallo @MAM59 es war viel Text von mir, deswegen ist bestimmt die Info vorbei gegangen... Direkt unter diesen Satz schrieb ich: Ich hab also die aktuelle IPv6 von Nginx Proxy Manager (auch die aktuelle öffentliche IPv4), dies bestätigt auch Nslookup.io wenn ich meine Domain eingebe. Aber folgendes Fehlerbild: Aufruf extern (DSL Anschluss mit Dual Stack): - ping auf meine Domain gibt die öffentliche IPv4 als auch die Standart Antwort zurück - ping -6 gibt die IPv6 des NPM zurück, aber als Antwort "Zielhost nicht erreichbar." (oder auch "Ping-Anforderung konnte Host "meineDomain.de" nicht finden. Überprüfen Sie den Namen, und versuchen Sie es erneut.") - ping -4 auf meine Domain gibt die öffentliche IPv4 zurück als auch die Standard Antwort zurück - gebe ich die IPv6 direkt in Browser ein (http://[IPv6] lande ich auf der "Gratulations Website" vom NPM Aufruf intern (DSL Anschluss ebenfalls Dual Stack): - ping auf meine Domain gibt die öffentliche IPv4 als auch die Standart Antwort zurück - ping -6 gibt die IPv6 des NPM zurück, aber als Antwort "Zielhost nicht erreichbar." - ping -4 auf meine Domain gibt die öffentliche IPv4 zurück als auch die Standard Antwort zurück - gebe ich die IPv6 direkt in Browser ein (http://[IPv6] erhalte ich "Die Website ist nicht erreichbar" "ERR_CONNECTION_TIMED_OUT" Ich habe es sowohl mit als auch ohne Eintrag der Domain im DNS Rebind Schutz der fritzbox versucht. Dies hat keine Auswirkung.

Hallo Zusammen! Ich hab noch ein Verständnis Problem und wäre an einer Lösung interessiert, wo ich nicht IPv6 ausschalten muss. Gerade in Hinblick auf die Zukunft führt eh kein weg an IPv6 vorbei. Kurz zu meiner Geschichte; Ich bin kürzlich umgezogen und musste zwecks Verfügbarkeit sowohl das Medium als auch Ambieter wechseln. ALT Breitbandnetz und Pyur (Telecolumbus) NEU DSL Netz und Vodafone Indem Zuge auch der Wechsel von einer Fritzbox 6591 auf Fritzbox 7590AX Durch den Wechsel habe ich aber meine öffentliche IPv4 verloren, und vom neuen Anbieter nur eine private bekommen (CGNAT). Nach einen Anruf bei Vodafone und ein paar Tage später erhielt ich aber zum Glück wieder eine Öffentliche Adresse. (Dual Stack) Ich habe die Einstellungen der alten Fritzbox rausgeschrieben und sie auf die neue übertragen. Seitdem habe ich das Problem, dass ich im lokalen Netzwerk nicht auf meine Nextcloud zugreifen kann Fehlermeldung "net::ERR_CERT_AUTHORITY_INVALID" , extern über Mobilfunknetz oder an einen anderen DSL Anschluss aber problemlos. Das liegt daran, dass in der alten Fritzbox IPv6 für Kabel nicht aktiviert war, in der neuen aber schon. Klar könnte ich das jetzt einfach wieder deaktivieren, ist aber nicht Sinn und zweck wie ich finde. Wenn ich die Domain in der Kommandozeile anpinge, bekomme ich sowohl lokal als auch extern die IPv6 der Fritzbox angezeigt. (Da IPv6 beim Verbindungsaufbau bevorzugt wird, ist dies korrekt, nur die Adresse passt noch nicht) Was mich aber hier bereits wundert, warum trotz des falschen AAAA Record, der Zugriff von Außerhalb über die Domain funktioniert.🤷‍♂️ Also habe ich mich ein wenig in die Thematik IPv6 belesen... okay NAT gibt es hier nicht mehr und dementsprechend keine Portweiterleitungen mehr sondern nur noch Portfreigaben direkt für das jeweilige Geräte/Dienst/Docker. Ich nutze den Docker NGINX Proxy Manager Official von @mgutt und hatte diesen bis jetzt auf "Custom : eth0" mit der IP 192.168.188.10 und die Ports 80 und 443 in der Fritzbox geöffnet. Da hier IPv6 nur vernünftig funktionieren soll, wenn dieser im Host Mode läuft, habe ich im ersten Step die Unraid Ports auf 5000 & 5001 geändert und anschließend NGINX auf HOST mode und die Portfreigabe 80 und 443 jetzt auf die Unraidmaschine in der Fritzbox geändert. Nextcloud ist extern weiterhin erreichbar, dies ist schonmal ein gutes Zeichen. Als DDNS Client nutze ich die Fritzbox und übermittle darüber die aktuelle IPv4 + IPv6 der Strato Domain. Was bei IPv4 okay ist, funktioniert bei IPv6 nicht, da hierdurch die Adresse der Fritzbox, wir aber die IPv6 des NGINX Proxy Manager übermitteln wollen. Also noch flux den Docker ddns-updater eingerichtet (ebenfalls im Host mode) und schwubbdiewupp habe ich die aktuelle IPV6 des Nginx Proxy Managers. Soweit so gut. Ab hier wird es für mich Strange und komme nicht weiter: extern: Rufe ich die IPv6 im Browser auf, lande ich auf den NGINX PM. Führe ich ein ping der Domain durch, erhalte ich die IPv6 vom NGINX NPM aber keine Antwort sondern "Zielnetz nicht erreichbar" Im Browser komme ich aber über die Domain auf meine Cloud. lokal: Rufe ich die IPv6 auf, erhalte ich in Chrome die Meldung "ERR_CONNECTION_TIMED_OUT" Führe ich ein Ping der Domain durch, erhalte ich meine öffentliche IPv4 adresse und auch die Anwort. Im Browser komme ich ebenfalls über die Domain auf meine Cloud. Ich meine es funktioniert, aber wo habe ich ein Denkfehler. "Sauber" ist das irgendwie noch immer nicht.

Hello everyone, I expanded my server to a total of 128GB RAM and, by a lucky coincidence, upgraded it from the E-2176G to the E-2278GE. Now I started my MacOS VM (Ventura) again to see if it still works --> Yes, it still works. So I shut down the VM and then gave it 64GB and expanded the cores from 4 (8 threads) to 8 (16 threads). Then run the helper script and then start the vm again. Unfortunately, I discovered that with the new config the VM takes significantly longer to start. (It used to be about 1 minute, now it's about 3-4 minutes), I also see that in the utilization of the CPU cores. For a while, only one core is used, until later all cores are involved. Now I tried a little and with the following arguments the VM starts in just under 40 seconds: <qemu:arg value='host,vendor=GenuineIntel,+hypervisor,+invtsc,kvm=on,+fma,+avx,+avx2,+aes,+ssse3,+sse4_2,+popcnt,+bmi1,+bmi2'/> Originally, as I found it online, it also said "+sse4a", but this caused the following errors in the log: qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.sse4a And the standard configuration before looked like this: <qemu:arg value='host,kvm=on,vendor=GenuineIntel,+invtsc,+hypervisor'/> Now I've been looking for quite a while, but unfortunately I haven't found anything specific. What do all the points do, is there a list for them and can I use them to get something out of performance or optimize it?

Einen schönen Pfingstmontag euch allen, ich melde mich wieder zurück und kann berichten, dass der Server jetzt mit 128GB RAM läuft. Ich bin, nachdem mir @DataCollector Wertvolle Tipps mit mitgegeben hat, nochmal die verschiedenen Punkte durchgegangen. - DUAL Channel ausschalten --> keine Option im BIOS vorhanden - Speichertakt Einstellung fix auf 2666 setzen --> ebenfalls keine Option vorhanden - RAM-Riegel in verschiedenen Bänken probiert --> kein Booten mit 4 Modulen möglich Letztendlich habe ich jetzt noch ein weiteren Riegel mit 3200Mhz gekauft und diesen mit den 2933MHz Riegel ausgetauscht, damit läuft die Kiste nun wie gewünscht.

Ja das Stimmt. ist leider so gewachsen😀 Wenn ich die KSM32ED8/32ME Module bekommen hätte, wären es auch die geworden. Das ist Interessant. Wie gesagt, die Zeit habe ich nicht gestoppt, ich denke so 2-3 Minuten. Da ich das Startverhalten aber nicht als normal erachtet habe, habe ich dann auch abgebrochen. Ich hatte es auch 2mal, dass nach diesen An,Aus,An,Aus der Server länger anblieb für vielleicht so 45s , dann wieder ausging, dann wieder 45s an etc. Da ich aber auch keine Ausgabe auf dem TV bekommen habe, auch hier abgebrochen. Was ich noch vergessen habe: - dass ich ein Pieper verbaut habe und dieser bei den Konstellationen die nicht funktioniert haben, kein einziges mal gepiept hat. - die Num-Lock Taste einer angeschlossene USB-Tastatur hat dann ebenfalls nicht aufgeleuchtet Ich glaube hier hast du dich verlesen😉 Ich habe 2x Alt (1x KSM29ED8/32ME 1x KSM32ED8/32ME) und 1x Neu (KSM32ED8/32HC) verbaut. In dieser Konstellation läuft der Server auch gerade den 2ten Tag durch. Mit der Information von dir werde ich das nochmal Probieren. Das sind auch nochmal sehr wertvolle Tipps, die ich gerne Probiere! Vielen Dank🍻🍻 Die Info ist auf jeden Fall Gold Wert!!! Ich habe früher öfters am PC's geschraubt aber das ist auch ne Weile her und da ist mir sowas nicht untergekommen. Das Stimmt. Ich habe auch gelernt, dass man solche Aktionen nicht Abend's mal schnell machen sollte in der Hoffnung "wird schon gehen" . Kurz vor 22 Uhr angefangen und 2 Uhr war ich froh das die Kiste wieder läuft, da auch ein paar Docker nicht mehr so wollten. (Durch das CMOS reset war jetzt Standartmäßig die dGPU gesetzt, was ich erstmal nicht geblickt hatte) Puhh... ich hoffe nicht. Dass müsste ich dann irgendwann mal anders Timen. Ich brauche Nextcloud und IoBroker täglich andere Docker ebenso. Gut zu Wissen! Vielen vielen Dank für deine Ausführliche Hilfe. Ich werde mal Schritt für Schritt alles durchgehen und melde mich wieder mit neuen Erkenntnissen.