Weiß ich nicht, was Ugreen da treibt. Wenn ich meine DXP4800plus mit https://dxp4800plus:9443 lokal aufrufe, bekomme ich eine Fehlermeldung, dass das Zertifikat ungültig sei. Geht das bei dir?
Edit: eineb, dieses UGREENlink kenne ich nicht, ist das sowas wie Quickconnect bei Synology?
Posts by Benares
-
-
Nein, der Haken allein reicht wohl nicht, der sorgt m.E. nur dafür, dass jemand auf https umgeleitet wird, wenn er über http reinkommt.
Aber dazu muss https erstmal funktionieren, also mit gültigem Zertifikat usw.Auf dem NAS habe ich es noch nicht probiert, aber auf meinem vServer habe den "Nginx Proxy Manager" in Docker am laufen. Der lauscht extern auf die beiden Standard-Ports 80 (http) und 443 (https) und leitet dann namensabhängig an den entsprechenden Dienst weiter (z.B. http(s)://nextcloud.meinedomain.de -> http://vserver.meinedomain.de:8080. Außerdem kümmert er sich auch um ein gültiges LE-Zertifikat für meinedomain.de und *.meinedomain.de und dessen Verlängerung.
-
Da bin ich ganz anderer Meinung. Wenn jemand was im Internet veröffentlich möchte, sollte er dies auf einem Server im Internet tun, und nicht irgendwelche Hintertürchen für den Zugriff aufs eigene Heimnetz öffnen, Heimnetz ist Heimnetz und das bleibt zu.
-
Gute Idee. Ich betreibe auch Nextcloud auf meiner DXP4800plus, aber nur lokal über http.
Aber ich habe auch gerade eine Nextcloud auf einem vServer bei ST-Hosting aufgesetzt. Meine Domain habe ich bei Netcup. Auf dem vServer läuft auch ein NPM-Container, der kümmert sich um die Erneuerung der LE-Zertifikate und regelt als Reverse-Proxy auch den Zugriff auf meine anderen Container dort, abhängig vom Namen und um die Umleitung http->https. So komme ich, z.B. mit http(s)://nc.meinedomain.de und gültigem LE-Zertifikat immer sicher auf meine Nextcloud. -
Um das mal hier etwas abzukürzen:
Die Meldung besagt, dass er sich mit https zu einem Server 192.168.178.65 (dein NAS?) über Port 449 verbinden will und das Zertifikat dafür wohl nur ein selbstsigniertes ist. Google mal nach "curl error 60". -
Nochmals eine ganz andere Ecke. Nextcloud als VM anstatt Docker-Container.
Aber eigentlich funktioniert letzteres schon ganz gut, bis auf Kleinigkeiten, insbesondere wenn Docker da einige Beschränkungen hat. -
Portainer/Dockhand funktioniert schon parallel und zwar sehr gut.
Mich stört nur, dass man mit den Stacks etwas fummeln muss, je nachdem, worüber man sie einspielt. -
UUps, heute geht's wieder. Gestern kam überall "Connection lost". Man muss es nicht verstehen. 😂
-
Ich nutze Dockhand gerne, vor allem , weil es auch sowas wie Watchtower integriert hat und mich veraltete Container auf Knopfdruck updaten lässt. Momentan kämpfe ich aber mit dem Problem, dass nur Portainer eine Konsole auf den Containern öffnen kann, Dockhand nicht.
Weiterhin stört mich, dass Portainer-Stacks nicht automatisch auch zu Dockerhand-Stacks werden und umgekehrt. -
alter Mann, danke, das kenne ich aber schon alles. Da hab ich u.a. die Informationen ja her.
Ich dachte da jetzt eher an eigene Erfahrungen. -
Ich kämpfe gerade mit einer Nextcloud-Installation auf einem vServer. Auf meiner DXP4800plus lokal klappt das ja ganz gut. Vielleicht passt das ja thematisch sehr gut hier her. Hat jemand Erfahrungswerte dazu?
Eckdaten: vServer bei ST-Hosting, 4 Cores, 4GB RAM, 100 GB Storage, Docker-Compose momentan so:Code
Display Moreversion: '2' services: db: image: mariadb:latest restart: unless-stopped command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --character-set-server=utf8mb4 --collation-server=utf8mb4_bin volumes: - /volume1/docker/nextcloud/db:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD=pass1234 - MYSQL_PASSWORD=pass1234 - MYSQL_DATABASE=nextcloud - MYSQL_USER=nextcloud # HIER DIE BEGRENZUNG deploy: resources: limits: memory: 512M # Beispiel: 512 MB RAM Limit reservations: memory: 256M # Reservierter Speicher app: image: nextcloud restart: unless-stopped ports: - 8080:80 links: - db volumes: - /volume1/docker/nextcloud/html:/var/www/html environment: - MYSQL_PASSWORD=pass1234 - MYSQL_DATABASE=nextcloud - MYSQL_USER=nextcloud - MYSQL_HOST=db - PHP_UPLOAD_LIMIT=1G - PHP_MEMORY_LIMIT=1G - POST_MAX_SIZE=1G - APACHE_BODY_LIMIT=0 deploy: resources: limits: memory: 1G # Hartes Limit: Nextcloud darf nicht mehr als 1G nutzen reservations: memory: 512M # Reservierter Speicher
Die Limits musste ich einführen, da sonst Nextcloud den den ganzen Server manchmal lahmlegt und Uploads kaum noch funktionieren.
Zusätzlich musste ich auch noch mit 'filelocking.enabled' => false in der config.php das File-Locking deaktivieren, da sonst nach einem fehlgeschlagen Massen-Upload gar nichts mehr geht.
Hat jemand irgendwelche Tipps? -
-
-
Hi,
willkommen im Forum.
Dann schau halt mal, wodurch das kommt. Log dich z.B. per ssh auf der Konsole ein und suche z.B. mit "find /volume1 -cmin -5" was sich in den letzten 5 Minuten geändert hat. Dadurch findest du vielleicht den Übeltäter. -
Mich stört das auch. Ich habe mir das eben mal angeschaut. Die Platten wachen bei der Anmeldung an UGOS wohl auf, weil /volume2/@tmp bei der Anmeldung wohl neu angelegt wird, obwohl nichts drinsteht (find /volume2 -cmin -10). Sonst passiert da nichts. Auf /volume1 (NVMEs) ist es ebenso. Ihr könnt ja mal schauen, ob das bei euch auch so ist.
Warum weiß ich nicht, wäre aber sicherlich leicht zu beheben. -
Wenn ich dich schonmal hier habe, hast du Erfahrung mit VPN Site-2-Site und der Namensauflösung.
Es sind zwei Fritz!Boxen leider nur mittels IPSec und einige meiner Container sind erreichbar mittels IP-Adresse, aber ich will die container_host_name.fritz.box Namensmuster einsetzen.
Sorry, nein. Ich experimentiere gerade mit einem 1€/Monat-vServer bei IONOS, auf dem ich eine Wireguard-Verbindung zu meinem Heimnetz eingerichtet habe. Der hat eine feste IPv4 und IPv6 und auch Docker und den Nginx Proxy Manager installiert. Als Domain habe ich 2 eigene bei Netcup. Darüber lässt sich ziemlich viel mit Subdomains und CNAMEs machen
-
Noch ein Hinweis zur Metric. Die ist immer dann wichtig, wenn es mehrere Wege zum gleichen Ziel gibt, beispielsweise wenn ein Host mit mehreren Interfaces ins gleiche Netz geht. Das schnellere der beiden sollte einfach eine niedrigere Metric haben als das langsamere, der absolute Zahlenwert ist irrelevant. Früher hat man einfach die Anzahl der Rechner dazwischen (Hops) als Metric verwendet.
Mal ein Beispiel:
Meine DS1522+ hängt mit 2 LAN-Interfaces in meinem Netzwerk, eth0 mit 1GBit/s als 192.168.0.70 (wegen WOL) und eth4 mit 10GBit/s als 192.168.0.71, meine DXP4800plus nur mit einem Interface eth0 als 192.168.0.81.
Synology ist da leider etwas blöd, man kann zwar ein Netzwerk-Interface priorisieren (Dienstreihenfolge), aber das ändert nur das Routing zum Default-Gateway, also nach außen. Entscheidend ist, was "ip route show" und "ip -6 route show" sagt.
Nach einem Reboot sieht das Routing der DS1522+so aus:Code
Display Moreroot@DS1522:~# ip route show default via 192.168.0.1 dev eth4 src 192.168.0.71 ... 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.70 192.168.0.0/24 dev eth4 proto kernel scope link src 192.168.0.71 root@DS1522:~# ip -6 route show 2001:16b8:bb23:f300::/64 dev eth0 proto kernel metric 256 expires 7199sec mtu 1492 pref medium 2001:16b8:bb23:f300::/64 dev eth4 proto kernel metric 256 expires 7199sec mtu 1492 pref medium fd58:218f:caa5::/64 dev eth0 proto kernel metric 256 expires 7199sec mtu 1492 pref medium fd58:218f:caa5::/64 dev eth4 proto kernel metric 256 expires 7199sec mtu 1492 pref medium fe80::/64 dev eth0 proto kernel metric 256 mtu 1492 pref medium fe80::/64 dev eth4 proto kernel metric 256 mtu 1492 pref medium default via fe80::e208:55ff:fe0e:169b dev eth4 metric 1024 pref medium
Wie man sieht ginge zwar der Traffic nach außen über eth4, aber intern ginge der Traffic ins eigene LAB über eth0 raus, da für beide die gleiche Metric (256) vergeben wird.
Also habe ich mir ein kleines Script geschrieben, das die Metric von eth0 auf 1024 (egal, Hauptsache größer als eth4) erhöht.
Danach sieht es dann so aus:Code
Display Moreroot@DS1522:~# ip route show default via 192.168.0.1 dev eth4 src 192.168.0.71 ... 192.168.0.0/24 dev eth4 proto kernel scope link src 192.168.0.71 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.70 metric 1024 root@DS1522:~# ip -6 route show 2001:16b8:bb23:f300::/64 dev eth4 proto kernel metric 256 expires 7199sec mtu 1492 pref medium 2001:16b8:bb23:f300::/64 dev eth0 proto kernel metric 256 expires 7199sec pref medium 2001:16b8:bb23:f300::/64 dev eth0 proto kernel metric 1024 pref medium fd58:218f:caa5::/64 dev eth4 proto kernel metric 256 expires 7199sec mtu 1492 pref medium fd58:218f:caa5::/64 dev eth0 proto kernel metric 256 expires 7199sec pref medium fd58:218f:caa5::/64 dev eth0 proto kernel metric 1024 pref medium fe80::/64 dev eth4 proto kernel metric 256 mtu 1492 pref medium fe80::/64 dev eth0 proto kernel metric 1024 mtu 1492 pref medium default via fe80::e208:55ff:fe0e:169b dev eth4 metric 1024 pref medium
und ein "iperf3 -c dxp4800plus" läuft dann mit 10GBit/s und nicht nur mit 1Gbit/s -
Das Problem besteht bei mir nur wenn ich über meinen Reverse-Proxy auf das NAS zugreife, wenn ich über die lokale IP des NAS zugreife werden die Icons korrekt dargestellt.
Na dann würde ich mal auf die Konfiguration deines RP schauen. Was unterscheidet den denn gegenüber dem direkten Zugriff, und was sagen dessen Logs?
-
Was hat das mit dem Problem von Andreas Franke zu tun?
Andreas Franke, Frage: Passen die Icons noch, wenn du oben links auf
The content cannot be displayed because you do not have authorisation to view this content.
klickst? -
Heute gab's eine neue Version der DLNA-App - leider ohne Change-Log. Schau mal, ob es damit wieder funktioniert.