Ja ok, aber da bin ich jeweils wegen meinem Problem oder Konfigurationswunsch nicht fündig geworden.
Mich wundert halt, dass es bei allen anderen Containern, die ich bisher installiert habe, nie ein Problem war.
Aber gut vielleicht ist Owncloud "hard coded" in der Hinsicht, auch wenn ich nicht verstehe, wie die das geschafft haben bzw. ob man das irgendwo ändern kann.
Zur Not muss ich damit leben, auch wenn ich nicht glücklich darüber bin..
Nö, ich meinte kaum dokumentierte owncloud environment settings.
Dass man bei Docker alle möglichen Variablen setzen kann, ist mir schon klar.
Danke für den Tipp, brachte nur leider nichts. Aber schon spannend, dass es Environment variablen gibt, die nirgends so wirklich dokumentiert ist.
owncloud-server startet nicht bzw. bricht mit Fehlermeldung ab:
Ich habe es auch mit anderen Environment Variablen, die mit Volume zu tun hatten, versucht. Hat auch nicht geklappt.
Habe den Ordnernamen auf owncloud geändert.
Hat leider nichts gebracht. Immer noch Fehlermeldung beim Starten des Containers.
Ich habe noch vieles weiter probiert:
Verhindern, dass Berechtigungen und Benutzer von owncloud verändert werden:
- OWNCLOUD_SKIP_CHOWN=true
- OWNCLOUD_SKIP_CHMOD=trueBrachte keine Besserung.
Dann habe ich nochmal den User festgelegt (bei mir der admin-user):
user: 1000:10Brachte leider auch keine Besserung.
Allerdings habe ich jetzt eine andere Fehlermeldung, vielleicht sagt die etwas aus?
P.S.: Mit OWNCLOUD_SKIP_... lief es auch auf volume1 nicht mehr
Selbst manuelles setzen der Berechtigungen mittels chmod bringt nichts.
Stand vor Start und nach Beenden von Owncloud (soll auf volume2 speichern):
==> owncloud-server meldet Fehlermeldung
Danke für den Tipp. Habe ich schon versucht. Brachte leider nichts.
Habe auch
user: 1000:10versucht. Hat auch nicht geklappt.
Um sicherzugehen habe ich auch einmal ein anderes Verzeichnis eingetragen, bei dem ich zu 100% weiß, dass ein Docker-Container Daten schreiben kann. Hat für owncloud auch nicht funktioniert.
Es scheint zumindest kein Berechtigungsproblem mit dem Verzeichnis zu sein.
Für mich sieht es so aus, als wäre das eine Beschränkung seitens OWNCLOUD. Die ist für mich aber leider nicht nachvollziehbar und ich habe bisher keine näheren Infos gefunden.
So habe jetzt auch mal versucht das Docker-Projekt direkt auf dem volume2 zu erstellen. Da mag mariadb auf einmal nicht ("Can't create test file ... (Errcode: 13 "Permission denied")")
Es ist echt zum Haare raufen.
Also nochmal
Verzeichnisberechtigungen vor Start von owncloud:
Verzeichnisberechtigungen nach Beenden von owncloud auf volume1:
Verzeichnisberechtigungen nach Beenden von owncloud auf volume2 (owncloud, mariadb & redis sollen alle auf volume2 speichern):
(mariadb liefert Fehlermeldung)
Nächster Versuch: Berechtigungen zurückgesetzt; nach Beenden (owncloud auf volume2, mariadb & redis auf volume1):
(owncloud-server liefert Fehlermeldung)
==> anscheinend verändert owncloud die Berechtigungen bzw. Besitzer der Verzeichnisse. Ich frage mich aber trotzdem, warum dass dann auch volume1 einwandfrei klappt und auf volume2 nicht..
Volume1 ist der gültige Pfad, volume2 ist auskommentiert.
Also ist immer entweder volume1 oder volume2 auskommentiert, damit ich nicht das ganze jedesmal neu eintippen muss.
Also kurz zusammengefasst::
volume2 auskommentiert --> volume1 nicht ----->owncloud startet
volume1 auskommentiert --> volume2 nicht ----->owncloud startet nicht (Fehlermeldung)
Hallo zusammen,
bin gerade etwas verzweifelt.
Ich habe owncloud via docker-compose installiert und zwar gemäß https://doc.owncloud.com/server/next/ad…mpose-yaml-file
Lokale Änderungen um den Zugriff über macvlan zu machen habe ich durchgeführt.
Lasse ich "redis" "mariadb" und "owncloud" auf mein docker-Verzeichnis (in dem andere Docker Container ebenfalls ihre daten speichern) zeigen, klappt alles und ich habe vollen Zugriff auf owncloud (lokal und auch von außen).
Beispiel mapping für owncloud:
volumes:
- /volume1/docker/owncloud/data:/mnt/data # change according your configuration
# - /volume2/owncloud-data:/mnt/data # change according your configurationich möchte aber gerne die Daten auf den Festplatten (volume2) anstatt auf der SSD (volume1) gespeichert haben (siehe oben auskommentiertes volume).
Allerdings startet der Server nicht, wenn ich auf volume2 umleite. Ich bekomme eine Fehlermeldung:
Cannot write into "config" directory!und
touch: cannot touch '/mnt/data/files/owncloud.log': Permission deniedDas komische ist: auf /volume2/owncloud-data wurden einige Unterverzeichnisse von owncloud erstellt, d.h. der Zugriff (Berechtigungen) müsste grundsätzlich möglich sein.
Hat irgendjemand Ideen?
Umgekehrt! Im Container definierst du eine IP-Adresse. Mit MacVLan schaffst du nur die Möglichkeit eines eigenen IP-Bereichs. MacVlan funktioniert also fast wie ein Router. (Zumindest sieht es so aus)
Mann, mann, mann... ihr seid mir so welche... jetzt muss ich das auch bestellen.... 
Hi zusammen,
In diesem Tutorial stelle ich Euch eine Anleitung zur Verfügung, mit der ihr die Entwicklungsplattform Gitea installieren könnt. Gitea ist ein minimalistischer Git-Server, mit dem man seine Softwareprojekte verwalten kann (Versionsverwaltung, Bug Tracker, Wiki etc.)
1. Per SSH auf Eere NAS verbinden (muss natürlich aktiviert sein)
2. Mit eurem Admin-Account anmelden
3. id ausführen
4. Werte für UID und GID notieren
1. Dateimanager öffnen
2. Verzeichnis gitea im Docker-Verzeichnis erzeugen
3. Im Portainer neuen Stack oder im Docker neues Projekt (Compose-Konfiguration) mit Namen "gitea" anlegen
4. folgenden Code in die Konfiguration kopieren:
services:
server:
image: docker.gitea.com/gitea:latest
container_name: Gitea
hostname: Gitea
restart: unless-stopped
volumes:
- /volume1/docker/gitea:/data
- /volume2/gitea-repositories:/data/git/repositories # Verzeichnis für Repositories, löschen wenn kein eigenes Verzeichnis gewünscht
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- '3000:3000' # Port für Webzugriff
- '22:22' # Port für SSH-Zugriff
environment:
- USER_UID=1000
- USER_GID=10
- GITEA__SERVER__ROOT_URL=http://192.168.178.200/ # Gewünschte (Sub-)Domain eintragen
labels:
- "com.centurylinklabs.watchtower.enable=true" # Watchtower Label für automatische Updates
networks:
default:
ipv4_address: 192.168.178.200 # IP-Adresse gemäß eigenen Wünschen anpassen
networks:
default:
name: mvl # Namen entsprechend eigenem MacVlan anpassen
external: true5. Deploy bzw. Bereit stellen
6. Gitea ist über http://192.168.178.200:3000 erreichbar
Viel Spaß damit
In diesem Tut verwenden wir KEIN MacVlan und KEIN Nginx, oder liest du das irgendwo?
Stimmt. Ich hatte auch nur laut darüber nachgedacht, ob das nicht auch geht. Wäre zu schön gewesen. Aber egal
Läuft das auch mit Routing über nginx? Wenn ja, wie muss man die YML Datei ändern und wie wäre die nginx-Konfiguration (insbesondere wegen der Ports)?
Dem hbbr und hbbs jeweils eine eigene IP-Adresse zuzuweisen, habe ich ja noch geschafft (mittels MacVlan). Damit wäre ja schon mal eine direkte Portzuweisung über den Router möglich, der an der Haupdomain hängt (z.B. beispiel.de).
Ich hätte aber gerne, dass rustdesk über eine Subdomain (z.B. rustdesk.beispiel.de) erreichbar ist. Die Subdomain wird über nginx bereitgestellt. Allerdings werden von nginx nur die Ports 80 und 443 weitergeleitet. Kann ich über die Weboberfläche einstellen, dass noch weitere Ports weitergeleitet werden?
Ist so ein Vorgehen nginx->rustdesk überhaupt sinnvoll?
IPv6 ist im Heimnetzwerk nicht sinnvoll, da stimme ich dir vollkommen zu. IPv4 reicht völlig.
Aber darum geht es hier ja nicht. Das war mein Versuch herauszufinden, ob damit vom LAN aus der Zugriff auf eine Subdomain server.beispiel.de möglich ist, wenn in der Fritzbox IPv6 aktiviert ist. Leider hat dieser Versuch nichts gebracht.
Da ich keine Ahnung von IPv6 habe, habe ich mich auf die Suche gemacht und die eben geposteten Zitate gefunden. Diese erklären zumindest, warum das nicht funktioniert.
Fazit: Es bleibt momentan wohl nichts anderes als IPv6 in der Fritzbox abzuschalten.
Aha, noch eine Info gefunden: (quelle)
Ah - da hätte ich möglicherweise einen Ansatz für Deine Recherchen:
Im Gegensatz zu IPv4, wo Dein Netzwerk nur über die öffentliche IP Deines Routers erreichbar ist, bekommt mit IPv6 jedes Gerät (und u.U sogar jeder Container) eine eigene öffentliche IPv6-Adresse (mindestens).Um direkt auf diese IPv6-Adresse zu verbinden, müsste ein DynDNS-Client auf dem jeweiligen Gerät die korrekte öffentliche IPv6-Adresse des Geräts an Deinen DynDNS-Anbieter melden.
Im Router braucht es dann nur die Portfreigaben für die entsprechenden Geräte.
und noch was: (quelle)
Wenn du IPv6 nicht brauchst/nutzt, kannst du es natürlich abschalten. Aber IPv6 gehört die Zukunft, deshalb sollte man sich frühzeitig damit beschäftigen.
Bei IPv6 gibt es keine Portweiterleitung mehr, nur noch eine Portfreigabe (Erlaubnis in der Firewall) und man spricht die IPv6-Adresse der Endgeräte direkt an. Die muss man natürlich DNS-auflösbar bekommen. Am einfachsten geht das mit MyFritz in Verbindung mit einer MyFritz-Portfreigabe, dann wird neben der IPv6 der Fritzbox über [myfritzid].myfritz.net auch z.B. ds923.[myfritzid].myfritz.net DNS-auflösbar. Die Namen sind nicht schön, aber man sie prima z.B. als CNAMEs in seiner eigenen Domain verwenden.
Sollte das eigentlich nicht der Rebind Schutz im Router wiederum abfangen und das ganze geht garnicht erst ins Internet raus? Oder irre ich mich da?
Ob ich den setze oder nicht, macht keinen Unterschied im Ergebnis.
Den Rebind-Schutz würde ich nur dann setzen, wenn eine entsprechende Meldung kommt, sonst nicht. Bisher ist die noch nicht aufgetreten. (Außer ich wollte direkt über mit ngix verwalteter Subdomain auf den Fritzbox Login drauf 
)
Aber grundsätzlich: woher soll der Browser wissen zu welcher IP-Adresse er muss, wenn einer zu server.beispiel.de will? Der Router weiß nicht wo die subdomain zu finden ist, also fragt er im Internet nach... (salopp gesagt)
Ach ja, ich habe beim DNS-Provider nur einen Eintrag für beispiel.de und *.beispiel.de. Vielleicht käme die Meldung, wenn ich auch server.beispiel.de eintragen würde, keine Ahnung. Aber genau das wollte ich ja vermeiden, dass ich jede einzelne Subdomain auch beim DNS-Provider eintragen muss (und nicht nur in nginx)
Zum Thema IPv6:
Ich habe weiter experimentiert und versucht mit IPv6 weiter zu kommen. Meine Vermutung (siehe oben) ist ja, dass die IPv6 Anfrage nicht weitergeleitet wird.
Das habe ich bisher unternommen:
Beim Aufruf der Subdomain server.beispiel.de von außen funktioniert immer noch alles einwandfrei.
Beim Aufruf im LAN lande ich auf der Fritzbox.
Es scheint also nicht an einer fehlenden Portweiterleitung für IPv6 zu liegen. Hat jemand Ideen? Vielleicht irgendwelche nginx settings?
P.S: versteht mich nicht falsch, ich kann auch mit dem Abschalten von IPv6 leben. Aber ich möchte wissen, ob man es nicht doch irgendwie mit eingeschaltetem IPv6 hinbekommen kann
Hallo zusammen,
diese Informationen habe ich aus verschiedensten Threads zusammen gesammelt und um meine eigenen Erfahrungen erweitert. Sollten sich mit der Zeit weitere Dinge ergeben, werde ich diesen Post entsprechend aktualisieren, damit möglich alles relevante an einer Stelle steht.
Wenn Ihr nur von eurem LAN aus auf eure eigenen (selbst ausgedachten) (Sub-)Domains wollt, also keine Verbindung von außen (vom Internet), dann folgt diesem Tutorial:
[TUT] Lets Encrypt https ohne offene Ports.
Router unterstützen meist IPv4 und IPv6. Vom Provider wird der Fritzbox deswegen meist eine öffentliche IPv4- und IPv6-Adresse zugewiesen. Der DNS-Eintrag der Domain (z.B. beispiel.de) zeigt daher sowohl auf die öffentliche IPv4- als auch die IPv6-Adresse der Fritzbox.
Per Default sind die in nginx konfigurierten Server nur über IPv4 erreichbar (keine IPv6-Adresse). Auch nginx ist nur über eine IPv4-Adresse erreichbar. Das Port-Forwarding der Fritzbox zeigt dann auch genau auf die IPv4-Adresse von nginx (oder sollte zumindest so konfiguriert sein).
Vom Internet aus ist das kein Problem, da der DNS-Server im Internet über den Provider zur Fritzbox leitet, die das Routing übernimmt und nginx die Verteilung an die Server entsprechend der Subdomain (z.B. server.beispiel.de).
Erfolgt der Zugriff aus dem LAN aus, sieht die Sache anders aus: Beim Aufruf der Subdomain im Webbrowser passiert folgendes: Der PC kennt die Subdomain nicht und fragt bei der Fritzbox nach. Die Fritzbox selbst kennt die Subdomain (z.B. server.beispiel.de) auch nicht und fragt daher beim DNS-Server im Internet nach. Der DNS-Eintrag im Internet zeigt auf die öffentliche IPv6-Adresse der Fritzbox. Die Fritzbox wird also direkt angesprochen. Da für IPv6 kein Port-Forwarding aktiviert ist, wird der Zugriffswunsch nicht weitergeleitet, sondern bleibt hängen.
Ich hoffe, die Erläuterung ist einigermaßen verständlich.
Wenn jemand weitere Informationen zu IPv6 hat, die hier helfen könnte, nur her damit. Ich integriere sie gerne.
Also ich hatte das Macvlan neu aufgesetzt (mit IPv6), danach nginx eine IPv6 Adresse und meinem Testserver (searxng) auch eine IPv6 Adresse gegeben. Konnte ich alles anpingen. Aber sobald ich die Domain aufrufe, lande ich wieder bei der Fritzbox.
Erst das Deaktivieren von IPv6 in der Fritzbox hilft (Fallback auf IPv4).
eineb Genau das tritt häufiger auf, daher bin ich auf IPv6 als mögliches Problem gestossen. Wenn ich genug Infos gesammelt habe, werde ich wohl einen allgemeinen Post machen, um das Problem und die mögliche Lösung zu beschreiben. Dann hilft das auch anderen, die das gleiche Problem haben. Aktuell ist diese Information ja ziemlich verstreut.
Super wäre es ja, wenn man das irgendwie beheben könnte, d.h. IPv6 nicht mehr abschalten müsste.
Ich konnte jetzt verifizieren (gestern war es einfach schon zu spät):
Es liegt eindeutig an IPv6, ich weiß nur noch nicht genau warum (kann nginx evtl. nicht mit IPv6 umgehen oder Portweiterleitungen funktionieren bei IPv6 nicht, oder Portweiterleitungen müssen für IPv6 bei der Fritzbox anders erfolgen?). Ich kenne mich zwar bei IPv4 einigermaßen aus, aber bei IPv6 noch nicht so wirklich. Ich muss mich diesbezüglich mal einlesen.
Fakt ist: Sobald ich IPv6 deaktiviert habe, funktioniert es. Ich brauche dann auch keine Einträge in DNS-Rebind und auch kein Adguard. Dabei spielt es keine Rolle, ob in der Fritzbox IPv6 nach außen oder nach innen deaktiviert ist. Ein Ping zur domain liefert dann auch ein IPv4-Adresse (die der Fritzbox)
Da es bei mir erst funktioniert hatte und am nächsten Tag nicht, lag wohl daran, dass die Verbindung an einem Tag über IPv4 und am andern Tag über IPv6 erfolgt ist.
Ich werde jetzt IPv6 wieder aktivieren und das über mehrere Tage verfolgen mittels Ping und Erreichbarkeit des Servers (Erreichbarkeit per IPv4 oder IPv6).
Ha, musste gar nicht lange warten. Sobald ich IPv6 aktiviert habe ging der Ping auf eine IPv6 Adresse und der Server war über die Domain nicht mehr erreichbar.
IPv6 deaktiviert (Router Advertisement in der Fritzbox) und schon geht der Ping auf eine IPv4 Adresse und die Domain ist wieder erreichbar.
