Crovaxon

Aah du hast den Container Pfad auch nochmal geändert, ja dann passt es ja. media_dir=/diska/platte21 Wäre damit auch korrekt. Sollten sich rein nur Medien in platte21 befinden, dann reicht auch nur die eine Zeile. Aber wenn du mini-dlna etwas weniger Arbeit beim durchsuchen machen willst, dann würde ich vorschlagen, dass du doch mehrere media_dir Zeilen machst und ihm nur die Ordner an die Hand gibst, die auch wirklich gesehen werden wollen, jetzt nicht jeder einzelne Ordner und Unterordner natürlich, aber eben die Hauptordner da drin wie Musik, Videos usw. Aber abgesehen davon drück ich die Daumen dass es jetzt klappt :)

Ausgehend von vorherigen screenshots hätte ich ja media_dir=A,/platte21/Musik media_dir=V,/platte21/Videos versucht an dieser Stelle. Zeig doch nochmal bitte in Unraid in den Docker container Einstellungen selbst, wie denn der Pfad jetzt konfiguriert ist, nicht der von /config sondern der andere, der in vorherigen Screenshots "Path: /platte21" genannt wurde. Wie sieht das aktuell aus?

Wenn du mehr als einen Ordner angeben willst, wirst du die config Datei von mini-dlna selbst anpassen müssen, ja. Ich weiß ja auch nicht, wie die eigentlich Konfigurationsdatei von mini-dlna aussieht und wie gesagt, die Vorkonfiguration geht von nur einem Verzeichnis aus, der als /media durchgereicht wird. Das sieht jetzt aber erstmal nicht verkehrt aus, was du da angegeben hattest, vorausgesetzt... Hattest du die Konfiguration denn auch soweit angepasst vom Docker container, dass hier Container-Pfad wieder /media sagt, oder nach wie vor /platte21? Wenn zweiteres zu trifft, würde deine Anpassung der Konfig zumindest richtig aussehen, denn dann weiß der Docker Container, dass es den Pfad /platte21 in seinem eigenen Dateisystem gibt und dann muss man es nur noch mini-dlna selber beibringen, da rein zu gucken. Beispielsweise: # set this to the directory you want scanned. # * if you want multiple directories, you can have multiple media_dir= lines # * if you want to restrict a media_dir to specific content types, you # can prepend the types, followed by a comma, to the directory: # + "A" for audio (eg. media_dir=A,/home/jmaggard/Music) # + "V" for video (eg. media_dir=V,/home/jmaggard/Videos) # + "P" for images (eg. media_dir=P,/home/jmaggard/Pictures) # + "PV" for pictures and video (eg. media_dir=PV,/home/jmaggard/digital_camera) media_dir=A,/platte21/Musik media_dir=V,/platte21/VideosErsetze /platte21 mit /media an dieser Stelle, falls du auch in Konfiguration vom Pfad /media als Container-Pfad wieder gesetzt hast. Falls du in der Konfig von mini-dlna selbst was anpasst, denk auch daran, den Container danach neu zu starten, damit die Software dadurch aus wieder neu gestartet wird. Wenn das aber alles auch nicht hilft, bin ich auch langsam mit meinem Latein am Ende, ich kenne die Software bzw. den Container eben nicht und gehe nur von dem aus, was ich in dessen Beschreibungen so sehe :)

Der Docker Container kennt kein /mnt/user/platte21. Überhaupt haben Docker container von alleine keinen direkten Zugriff auf das Dateisystem ihres hosts. Das System im Container sieht nur das was im Container selbst ist und sonst nix. Man muss einem Docker Container erst einen Pfad konfigurieren, der dem erlaubt, einen Ordner von deinem Host Dateisystem sehen zu dürfen. Dabei erhält diese Zuweisung innerhalb des Containers aber einen ganz eigenen Pfad. Das, was der mini-dlna container für /media hält, ist in Wahrheit /mnt/user/platte21, weil durch die Konfiguration der Container-Pfad /media mit dem Host-Pfad /mnt/user/platte21 verknüpft wird. Da wird nix kopiert oder sowas. Der Docker Container erhält lediglich Zugang zu dem Ort wo deine Medien tatsächlich liegen, nur dass er selber denkt, sie liegen in seinem eigenen Dateisystem und zwar unter /media. und der mini-dlna server im Container ist auch glücklich, weil dieser ab Werk vorkonfiguriert ist, nach einem /media Ordner zu schauen und diesen bereit zu stellen. Das ist einer der vielseitige Effekte, einen service durch einen Docker Container anzubieten. Die Software im Docker Container kann fest vor konfiguriert werden, auf ganz bestimmte Ordner innerhalb seiner kleinen Welt loszugehen, man muss die Software selber nicht mehr zwangsläufig konfigurieren, sondern nur die Gegebenheiten des Docker Containers selbst. Jeder Mensch kann sich jetzt dieses Docker Image nehmen, also diese Vorlage quasi, muss nur den Pfad entsprechend anpassen und anhand dessen den daraus resultierenden Container betreiben. Bei dir liegen deine Medien eben unter mnt/user/platte21, bei mir liegen sie vllt unter mnt/user/medien oder so. Für den mini-dlna im Container spielt das keine Rolle, das denkt, es redet mit /media ,und ist happy.

Also ich hab mir mal den mini-dlna docker angesehen, der will von dir 2 Pfade, einmal für die Konfiguration der Software selbst, die landet ja wie üblich in /mnt/user/appdata/container-name, das kann man so lassen so wie du es im screenshot hast. Und dann braucht es den Pfad wo die Medien selbst liegen und das Missverständnis liegt glaube ich darin, wie Docker Container und Pfad Zuweisungen verstanden werden. Mini Docker Exkurs: Ein Docker Container ist ein in sich selbst geschlossenes kleines System, wo normalerweise nur das nötigste läuft, welches die gewünschte Software zum funktionieren braucht. Also ein mini Betriebssystem + anderweitige Grundvoraussetzungen und natürlich die Software selbst. Ein Docker Container hat erstmal an für sich gar keine Ahnung von seinem Host, also dem Hauptsystem auf dem es läuft (Unraid hier in dem Falle) und läuft abgeschlossen innerhalb davon. Man muss ihm erst an die Hand geben, was es alles benutzen soll und darf. Das ist was man in der Konfigurationsmaske an der Stelle macht in der Form von Pfad Angaben oder Umgebungsvariablen und so weiter. Und hierbei ist die Konfiguration eines Pfades wie folgt zu verstehen: Was als Container-Pfad betitelt ist, ist was aus Sicht des Betriebssystems innerhalb des Containers gesehen wird. Host-Pfad aber ist, wo es tatsächlich auf der Maschine liegt. Die Angabe einer Pfad-Konfiguration ist also, wo sich ein Bereich des Dateisystems des Containers und das Dateisystem des Hosts die Hand geben dürfen. Kann man auch gut mit dem Einhängen von externen Medien wie USB Sticks oder Festplatten vergleichen, wenn das ein geläufiges Konzept ist. Du hängst hier nur quasi einen Ordner vom Host System in dem des Container Systems ein. Exkurs Ende :) Die Software innerhalb des Containers, in dem Falle mini-dlna, ist so vor konfiguriert, dass es einen /media Pfad erwartet zu finden. Bei jedem Unraid Nutzer liegen die Medien Dateien ja aber ganz individuell. Du passt also nur Host-Pfad an und hinterlegst dort /mnt/user/platte21, damit gibst du dem Container zu verstehen, dass es im Host den Pfad /mnt/user/platte21 gibt, auf den er dann lesend und/oder schreibend zugreifen darf und er sich diesen als /media in sein eigenes Dateisystem einhängen soll. Wenn man mit dieser Konfiguration dann den Container startet, kann das vor konfigurierte mini-dlna innerhalb des Containers also einfach direkt zu /media gehen und findet dort dann deine Medien. Unterm Strich also: passe die Pfad-Konfiguration, die jetzt bei dir den Namen Path: /platte21 hat so an, dass Container-Pfad wieder /media sagt und das sollte es gewesen sein.

Die WebCrypto-API Browser Funktionalität, die im web-vault wohl eine Voraussetzung ist, setzt eine sichere Umgebung voraus -> HTTPS Zwang. https://github.com/dani-garcia/vaultwarden?tab=readme-ov-file#usage Das gilt nicht für die Admin Oberfläche, die verwendet die WebCrypto-API wohl nicht. Auch keine Ahnung was die App da anders macht im Zugriff, aber der Browser basierte Zugriff auf deine Vault selbst will eben HTTPS. Und mit Vaultwarden lokal ansprechen kommt man da eben in die HTTPS im lokalen Netz Problematik, dass kann man verschieden lösen, häufig mit viel Kopfschmerz je nachdem was dein lokales Netzwerk Setup so hergibt. Ich hab mich selber einfach dazu entschieden in den sauren Apfel zu beissen und die externe URL meiner domain auch lokal zu verwenden. Bedeutet zwar, dass ich dafür eben traffic technisch kurz mein lokales Netz verlasse (Hüpfer zu dem Router meines ISPs, der mich dann wieder Richtung meines eigenen Router umbiegt, nehm ich mal an). Aber so klappts für mich und ist unkompliziert. Ein fester Eintrag deiner externen Domain und der IP deines Unraid servers in die hosts Datei von Windows könnte das vllt auch schon lösen? Macht natürlich am meisten Sinn, wenn die lokale IP deines Unraid Servers auch gleich bleibt (statisch oder DHCP Reservation). Setzt voraus, dass du mit deinem lokal zugreifenden Gerät auch immer nur lokal bleibst ;) Ansonsten muss man den Eintrag auch wieder entfernen, sobald das Gerät mal von woanders aus auf deine Domain zugreifen will. Hab ich mir deswegen erspart. Die alternative ansonsten ist, sich dann mit einem lokalen eigenen DNS Server rumzuschlagen, der für dich das Auflösen einer Domain auch komplett lokal machen kann, was ich mir bislang mangels Zeit erspart habe und leider keine Tipps selber zu geben kann...

In welcher Situation genau tritt das auf? Versuchst du die http Adresse lokal im Netz aufzurufen? Das geht nämlich von vornherein nicht, Vaultwarden verlangt https für den Zugriff auf die web-vault, Punkt. Einzige Ausnahme ist wenn du auch localhost für die Vaultwarden Instanz bist.

Welchen Redis Container verwendest du denn? Eig. sollte in den Einstellungen eine Option geben ein Volume für das Speichern der Daten anzugeben, ansonsten fliegen die ja nur innerhalb des Containers rum und sobald dieser mal neu gebaut wird aufgrund von z.B. eines Updates des Docker Images, wären die Daten ja sonst futsch. Ich selber hab den von jj9987 im Einsatz, allerdings weiß ich ausm Stegreif jetzt nicht, ob ich dort selber einen Volume Pfad angelegt hatte oder ob dieser bereits spezifiziert war. Ich kann den sowieso nicht mehr in den Community Apps selber auffinden, aber meiner tut weiterhin. Der Redis container von A75G jedenfalls hat eine Option, einen Pfad anzugeben, wo die Daten persistent gespeichert werden sollen.

Die denke informationsreichste und einfachste Info aus dem Terminal kriegst du mit dem dritten Befehl aus dem Beispiel von alturismo: df -h /mnt/user0 Der Terminal Befehl df gibt Info über belegten und freien Speicherplatz von Dateisystemen in deinem Gerät. Mit dem zusätzlichen Parameter -h dran gibt er die Werte in einem leichter leserlichen Format wieder, ansonsten gibts nur große Zahlen in 1 Kilobyte Blockgröße Der nächste Parameter ist der Dateipfad auf den wir uns beschränken wollen, ohne den kriegst du ansonsten alle Dateisysteme aufgelistet. Alle in Unraid angelegten Shares des Arrays liegen unter dem Pfad /mnt/user0/, also beschränkt man sich auf den. In alturismo's Beispiel hat er die Ausgabe Filesystem Size Used Avail Use% Mounted on shfs 33T 14T 19T 43% /mnt/user0 zurück bekommen. Das Dateisystem in dem alle shares sind, ist insgesamt 33T (Terabyte) groß, davon sind 14T belegt und noch 19T offen, also 43% des Arrays sind belegt.

Zum Thema Erreichbarkeit bezüglich IP: Fritzboxen sind so nice und geben direkt beim IPv4 Eintrag in der Liste an, ob diese einen DS-Lite Tunnel verwendet, weiß aber nicht ob sie dass auch für CGNAT tun. Sieht ja erstmal nicht so aus, dass die IPv4 aus dem Screenshot eine problematische wäre, da besagter Info Text fehlt. Grob gesehen kann man schonmal checken ob die IPv4 Adresse die die Box anzeigt, in einem von diesen Bereichen liegt: 10.0.0.0 - 10.255.255.255 100.64.0.0 - 100.127.255.255 (Carrier-Grade-NAT) 172.16.0.0 - 172.31.255.255 192.0.0.0 - 192.0.0.7 (DS-Lite-Tunnel, Dual-Stack-Lite) 192.168.0.0 - 192.168.255.255 Der Trick von Archonw mit "Was sagen außenstehende Seiten, mit was für einer IP Ich daher komme vs. was zeigt mir mein Router als WAN IP Adresse an" ist aber auch ein sehr guter Indikator dafür, ob man unter CGNAT/DS-Lite leidet. Ist das der Fall, sollte man erstmal mit dem Internet Anbieter reden, ob die einem eine eigene öffentliche IP geben können (bei CGNAT) bzw. full dual stack (im Falle von DS-Lite) und ob dieser Service mit Mehrkosten verbunden ist, die man willens ist, zu bezahlen. Einige ISPs sind ja sogar so nett und machen das einfach so, sie geben nur per Norm an jeden Kunden immer erstmal eine nicht selbsthosting freundliche Konfiguration, denn von allen Internet Nutzern ist es ja doch eher ein Bruchteil, der überhaupt was selber hosten möchte. Ansonsten gilt auch zu beachten, dass man eine Port Weiterleitung im Router anlegen muss, damit die Dienste auf deiner Unraid Maschine auch von außen erreichbar sind. Du sagst jetzt, NPM erstmal aus dem Spiel lassen, okay. Aber ich würd dennoch an deiner Stelle abraten, den Vaultwarden container selber zu entblößen, sondern doch lieber NPM, ist nämlich leichter zu testen. Sobald NPM grundsätzlich erreichbar ist, bekommst du die default Congratulations page zu sehen, sobald du deine Subdomäne ansurfst und NPM noch keinen Eintrag dafür hat, was er mit Besuchern deiner Subdomäne machen soll. Wenn du doch erstmal direkt pur mit Vaultwarden loslegen willst und dann auch HTTPS ans laufen kriegen willst, wirst du dich mit dem Spaß hier auseinander setzen müssen: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-HTTPS#enabling-https Wenn du doch mit NPM testest und da erfolgreich die Congratulations Page angezeigt bekommst, weißt du definitiv dass Selfhosting schonmal klappt und kannst direkt weitermachen. Dann muss innerhalb von NPM auch ein Proxy Host Eintrag existieren, der weiß, dass Besucher auf hugoigel.dyndns.xx zu deinem gewünschten Docker Container weitergeleitet werden sollen.

Da ich jetzt zufällig über die Unraid 7 patch notes gestolpert bin, hast du evt. Glück und das ist kein Problem in dieser Version mehr das wird wohl sein worauf Squid hinweisen wollte. https://docs.unraid.net/unraid-os/release-notes/7.0.0/#docker

Yeah, the lack of SSL / the registry being ran insecure seems to be the general issue. I finally got some traction in the German subforum with my thread there and in the end what had helped was switching to Gitea, which I had planned to reverse proxy out anyway (and Gitea also includes their own Docker registry). After I did that and moved some of my images over to its registry, I switched the containers to the public HTTPS URL of it and voila, no more problems for Unraid to detect image updates. Approaching Gitea directly without HTTPS also made Unraid not able to do version checks, so it indeed must be a secured registry it seems.

So, ich hab das mal ne Weile im Auge behalten, hatte auch mal nen Test gemacht, wo ich den port vom Registry docker auf 80 geschubst habe, um ne portnummer bei der repo URL zu vermeiden, Falls die repo:tag Erkennung da irgendeine Rolle spielen sollte. Aber auch dies änderte nix daran, dass Unraid bei diesem Container auf "Not Available" sprang nach einem check for updates. Ich denke Unraid mag schlicht keine insecure Docker Registries. Meine mittlerweile auch publike Gitea Instanz funktioniert derweil als alternative Docker Registry tadellos über die öffentliche URL angesprochen. Ich könnte jetzt zwar auch den alten Registry container durch mein Reverse Proxy lotsen, aber da ich eh Gitea habe und die Registry dort ebenso gut funktioniert, bleib ich jetzt einfach bei der und ziehe meine images dorthin um. Das Thema hat sich also für mich erstmal gegessen. Danke für die Anteilnahme.

Do you know by any chance if for Unraid's update check it takes a look at the repository link to identify the image tag to test against? Or if that is what would be fixed in the coming release? Given the screenshot of my previous post I get the sneaking suspicion that update checks fall flat because insecure repositories would typically be running on non default HTTP ports. Everything that is not 80 or 443 you need to specify in the URL as ip:port/image and the supposed Tag on my affected container starts at the port number, which is of course not the real image tag. Specifying ":latest" in the repo link does not change that behavior.

So, ich habe mich mal dran gemacht und mein Gitea auch mal nach draußen gehängt... Damit hat es jetzt eine schöne URL und ich hab einen container auf diese URL umgebogen. Und siehe da, nun klappts. Ich hab mal "Check for updates" laufen lassen und während meine alten auf der separaten registry laufenden Container weiterhin "Not available" melden, zeigt der neue auf meiner publiken Gitea Registry nun schön "up-to-date". Und ich hab auch ne schleichende Vermutung, woher das Problem stammt. Ohne jetzt Unraid's Quellcode zu wälzen... (es ist jetzt schon ein bissl spät und ich will ins Bett ) aber ich glaube Unraid macht es sich einfach beim Identifizieren von Repository und Image(plus Tag). Da wird einfach nach dem Doppelpunkt gesucht, weil dahinter kann dann ja nur ein Image Tag folgen, gell? Das haben wir bei einer lokalen IP auf einem nicht standard HTTP port allerdings nicht 😉dort gibts potenziell zwei Doppelpunkte, der erste bei der Portangabe und evt. ein zweiter für ein spezifisches Image Tag. Einmal oben mit meiner insecure registry auf port 5000, unten jetzt auf meiner publiken Gitea URL. Man sieht schon dass der erkannte Tag bei der insecure bereits nicht kosher ist. Da wurde einfach nach dem ersten Doppelpunkt vom Image Tag ausgegangen. Es hilft auch nicht, ":latest" spezifisch im Repository des Containers anzugeben. Das erste auftauchende Doppelpunkt wird als Tag Trennzeichen verwendet Ob dies nur rein visuell ist oder ob Unraid für sich selber auch so das image identifiziert, um damit dann das Repository auf Unterschiede zum laufenden Image zu testen ist jetzt hier die Frage. Ist natürlich nur ein Verdacht. Wenn es nicht so umständlich wäre, jetzt Port 80 bei mir mal frei zu machen, damit ich Docker Registry auf dem default HTTP Port horchen lassen kann, könnte man dies mal so testen, ob dies dann reibungslos funktionieren würde, wenn man dann 127.0.0.1/imagename ohne Portangabe einfach machen könnte und Unraid dann damit klar kommt. Mal schauen, vielleicht finde ich einen Moment morgen, damit ich das mal umbiegen und testen kann. Auf jeden Fall kann ich bestätigen, dass mit der Public URL es jetzt auch klappt.

Jo, hatte ich auch in selten Fällen, aber das sollte bei DockerHub usw. ja nicht die norm sein. Bei mir allerdings schon Mittlerweile ist der wieder umgesprungen auf "Not Available", wohl als ich gerade einen anderen Docker aus den community apps installiert habe und Unraid's Routine die Container durchgelaufen ist. Der JSON vom betroffenen Container sieht so aus: "local": "sha256:06e0e7f673fc011da77724d331921ba3bf26dc1619e58079d0a470eb820d56cc", "remote": null, "status": "undef" Remote ist jetzt schlicht null. Gitea hat da leider auch nicht geholfen. Vermutlich ist es eben doch die Tatsache, dass es insecure betrieben wird. Ich finds zwar affig, lokal direkt auf der Maschine miteinander sprechende Prozesse mit HTTPS absichern zu müssen, aber denke da komm ich nicht dran vorbei. @ich777, sprichst du deine Registry bzw. Gitea von einer public URL an, also von außen erreichbar oder ist das immer noch alles intern und der Container selbst ist mit HTTPS abgesichert?

Probier ich mal, ich hab gerade dasselbe image auf Gitea's Registry geschubst und einen meiner Container auf dessen repo umgestellt. Soweit ist es grün, aber das ist auch der Fall mit der standalone Registry gewesen nach dem ersten Erstellen oder nach einem force update, das war immer irgendwann auf "Not Available" gehüpft. Mal beobachten.

Ich seh auch grad in dem JSON, dass meine eigenen Container da jeweils "local": null, "remote": null, "status": "undef" stehen haben, dann auch kein Wunder dass keine Versionsabfrage klappt jetzt nur noch herausfinden, wo bei Unraid der Schuh drückt...

Ah das ist doch schonmal gut zu wissen. Es gibt ja den Standard Tag "Latest". Pushes auf ein Repo ohne Angabe eines Tags versieht diesen Push immer automatisch mit "Latest", oder man setzt halt händisch "Latest" in Kombination mit anderen Tags, damit "Latest" auch auf diesen bestimmten Push zeigt. Ich habe bei meinen Docker Selbstversuchen jetzt nicht speziell getagged, also zeigt "Latest" ja auch auf meinen letzten Push. Ich gebe bei meinen Containern in Unraid als Repo dann halt auch keinen speziellen Tag in Unraid an (also einfach localhost:5000/imagename), dieser holt dann standardgemäß auch "Latest". Und da ich generell hier noch unerfahren bin was Docker Bauen und eben die Registry angeht, war ich mir nicht sicher ob das Tagging da in irgendeiner Weise eine Rolle spielt. Aber dass da nur hashes verglichen werden macht ja Sinn. Und ja, Unraid muss dann wohl Schwierigkeiten haben, den Hash vom Remote abzufragen.

Ich hatte bereits mit images selber basteln angefangen bevor ich mittlerweile auch Gitea für mich entdeckt habe für Quellcode. Ich hatte images bei mir auf meinem Rechner gebaut und brauchte einfach ne repository zum drauf schubsen und abrufen und da kam Docker Registry als eigener container ganz gelegen. Das Gitea auch die Registry übernehmen kann hab ich gesehen und behalte ich weit im Hinterkopf, ich würde ja vorher lieber wirklich genau wissen, worauf Unraid's Erkennung für Updates auf einem Docker Image fußt. Sonst hab ich am Ende ja auch wieder denselben Salat, ob ich lokal auf der Maschine Gitea oder die standalone Registry absichern muss Kann ich beizeiten versuchen, statt localhost mal 127.0.0.1 oder die lokale IP zu nehmen. Was mich ja initial wundert ist, wie Unraid denn da eig. vorgeht. Es ja nicht so, dass das Ansprechen der registry nicht klappt, ich kann ja initial den Container aufsetzen oder auch bei bereits laufenden Containern das aktuelle Image über "Force Update" ziehen. Nur Unraid's Versionserkennung klappt kein bisschen. Tagst du deine Images noch auf irgendeine spezielle Weise?

Docker Registry, auch in den community apps verfügbar. Einfach add container, als repository "localhost:5000/imagename" und halt Rest ausfüllen wie es das eigene Image unterstützt Und ich persönlich hab da einfach nicht die Notwendigkeit gesehen, da ein Zertifikat vorzusetzen, wenn ich die Registry gar nicht außerhalb meines LANs ansprechen kann/will. Wenn ich das je mal exposen möchte, würde ich das eh über einen Reverse Proxy machen, der macht dann TLS. Zumindest Unraid selbst bzw. andere container können ja direkt mit dem Registry Container reden.

Ne bislang noch nicht. Bisherige Vermutung ist, dass die registry hinter https abgesichert sein muss, meine läuft über http, also insecure. Is there any thread about that? Would be very interested to keep an eye on this. Might this be because of my registry being insecure? It's all running purely local so I did not bother securing it via SSL cert nor am I operating a local DNS for my LAN space where I could put registry for secure access behind. Additionally I am still a greenhorn when it comes to docker creation, so I am also not sure if I have to observe anything specific about image tags or so for Unraid's image versioning to properly pick up that there is a newer version in the registry. Is anything more than just tagging it latest required?

Arrived here following after the crumbs of "exit status 255" errors, I had been using an old version of the script. Removed it from my go file and set up the new one as a userscript now. Seems all good and working now according to logs. Again thanks for this script and the effort to extend the life of cache SSDs

Hey folks, I had attempted to ask this over in Lounge and a couple other places before, because I am absolutely not sure if the fault isn't somewhere with me and the way I am doing it, but those attempts all remained unanswered, so I am trying for support this time. I am hosting my own Docker Repository as its own container, to push my own images to and make use of them for custom dockers I want to use within Unraid's docker tab. The Unraid version is 6.12.8. This all works pretty well, with one minor but slightly irritating thing: any of my custom dockers that refer to my local repository all sooner or later show "Not available" for its version. Which makes wanting to have them pull updates a little hassle. I always have to go into the advanced menu and have them force update to get the latest image I pushed and then have to remove the dangling left over image. It works of course but I would hope to solve this and have the process be a little smoother. It might fairly well be that I am doing something wrong with the whole setup. Is it because it is an insecure docker repository, aka running on HTTP? I don't expose it anywhere, the purpose of this registry is to be just used by Unraid itself so I'd hope not to have route it through a proxy and a deal with issuing a local cert. I might do that if its a requirement but I would be glad to hear first if that is truly necessary for Unraid to be able to do version checks on a repository.

Genau. Wenn du deine domain URL für Filebrowser ansurfst, sollte NPM bereits HTTPS verwenden! Und um zu gewährleisten das auch wirklich nur HTTPS von außen nutzbar ist, eben das "Force SSL" aktivieren in dem Eintrag zu Filebrowser in NPM. Check in deinem Webbrowser mal wenn du deine DuckDNS Adresse für den Filebrowser ansurfst, ob du oben in der Adresszeile dir die volle URL anzeigen lassen kannst. Steht da bereits https in der Zeile (bei Chrome muss man doppelt reinklicken, dann gibts die vollständige URL)? Oder sieh dir die Website Informationen an (bei Chrome z.B. ist dass das Symbol ganz links innerhalb der Adresszeile). Da sollte dann sowas stehen wie "Die Verbindung ist sicher" und du kannst dir das im Detail anschauen, vor allem das dahinter liegende Zertifikat, da sollte dann auch deins stehen, welches NPM per Lets Encrypt erzeugt hat.