ownCloud im Docker-Container: Probleme mit Zugriffsrechten

[mdawid]

Hallo Zusammen,

ich versuche gerade ownCloud im Docker zu installieren und habe dabei Probleme das data Volume von "/volume1/owncloud" einzubinden. Ich habe das Image von Docker Hub heruntergeladen, nach den Anweisungen konfiguriert und wollte mein Share-Laufwerk /volume1/owncloud als Volume für den Container einbinden. Leider erhalte ich beim Aufruf des initialen Einrichtungs-Assistenten von ownCloud die folgenden zwei Fehlermeldungen:

Data directory (/volume1/owncloud) is invalid

Please check that the data directory contains a file ".ocdata" in its root.

und

Cannot create "data" directory (/volume1/owncloud)

This can usually be fixed by giving the webserver write access to the root directory.

Was ich bereits versucht habe:

• Via DSM der Gruppe http, R/W Rechte auf das share /volume1/owncloud zu geben

• Via docker-shell mit "chmod 777 -R /var/www/html/data" dem ordner R/W rechte zu geben

• Via docker-shell mit "chown www-data:www-data -R /var/www/html/data" den Ordner als Eigentümer eintragen

• Via DSM FileStation Rechtsklick auf /volume1/owncloud -> Permissions -> http -> edit -> Read (Haken setzen), Write (Haken setzen)

Leider führt das auch nicht zum Erfolg. Kann es sein, dass ich einen User mit der passenden ID auf DSM haben muss, welcher die gleiche ID hat wie www-data im Docker Container? Wenn ja, wie kann ich das bewerkstelligen?

Das Volume /volume1/owncloud ist per DSM verschlüsselt, aber zum Zeitpunkt des Docker starts gemountet.

Gibt es eigentlich bereits eine Anleitung um ownCloud in einem Synology-Docker-Container einzurichten?

Danke,

Grüße,

Michael

 

[haydibe]

Ich habe das Image von Docker Hub heruntergeladen,

welches Image?

Ist es das hier?

Warum versuchst Du innerhalb des Containers Berechtigungen zu ändern?

Du musst dafür sorgen, dass die UID:GID aus dem Container auf /volume1/owncloud schreibend zugreiffen kann.

Entweder mit `chmod 777 /volume1/owncloud` oder in dem Du Dir einen Benutzer mit passender UID und eine Gruppe mit passender GID. Allerdings habe ich keine Idee, wie man das machen sollte. In einem ordinären Linux würde man dazu /etc/passwd und /etc/groups editieren.

Ich mag Docker-Images nicht, bei denen man die UID und GID nicht über Umgebungsvariablen mitgeben kann. Entweder solche Container mit Root-Rechten oder benutzen irgendeine wilde kombination aus UID:GID, so dass man bei dem Problem landet das du gerade hast.

 

[haydibe]

Persistent data

All data is stored within the default volume /var/www/html. With this volume, ownCloud will only be updated when the file version.php is not present.

-v /<mydatalocation>:/var/www/html

For fine grained data persistence, you can use 3 volumes, as shown below.

-v /<mydatalocation>/apps:/var/www/html/apps installed / modified apps
-v /<mydatalocation>/config:/var/www/html/config local configuration
-v /<mydatalocation>/data:/var/www/html/data the actual data of your ownCloud

Sprich bei dir müsste dann das lokale Verzeichnis "/volume1/owncloud" im Docker-Container unter "/var/www/html" eingebunden sein.
Zieh die Berechtigungen auf "/volume1/owncloud" sauber und alles sollte laufen!

 

[mdawid]

welches Image?

Ist es das hier?

Ja

Du musst dafür sorgen, dass die UID:GID aus dem Container auf /volume1/owncloud schreibend zugreiffen kann.

Entweder mit `chmod 777 /volume1/owncloud` oder in dem Du Dir einen Benutzer mit passender UID und eine Gruppe mit passender GID. Allerdings habe ich keine Idee, wie man das machen sollte. In einem ordinären Linux würde man dazu /etc/passwd und /etc/groups editieren.

Ich hab in diesem Beitrag gelesen, dass der Benutzer ein ähnliches Problem hatte. So wie es aussieht muss man per SSH die Datei /etc/passwd editieren, was mir nicht so lieb ist.

Ich mag Docker-Images nicht, bei denen man die UID und GID nicht über Umgebungsvariablen mitgeben kann. Entweder solche Container mit Root-Rechten oder benutzen irgendeine wilde kombination aus UID:GID, so dass man bei dem Problem landet das du gerade hast.

Ich denke ich schau mir mal einen anderen Container an. Der nächst bessere scheint interessant zu sein.

 

[mdawid]

Ich habe nur den share /volume1/owncloud als data auf den container gelinkt. Probiere jetzt mal die Rechte anzupassen

 

[mdawid]

Ich habe jetzt nochmal meine Webstation überprüft und festgestellt, dass noch eine alte owncloud Installation in meinem Web-Verzeichnis vorhanden war. Das bedeutet, die Fehlermeldungen die ich gesehen habe trafen gar nicht auf die Docker Container zu :-(.

Ich versuche jetzt erstmal den offiziellen Container zum laufen zu bekommen. Allerdings habe ich hier schon das Problem, dass ich erst gar nicht auf die Start-Seite von Owncloud komme - obwohl ich die entsprechenden Porteinstellungen im Docker-Container für die Ports 80 und 443 gemacht habe.

Das Problem wird wohl sein, dass ich owncloud gerne auf dem Alias /owncloud/ laufen lassen möchte. Ich habe bereits einen Alias in der Apache Konfigurationsdatei angelegt, aber ich komme immernoch nicht drauf :-(.

Im Container habe ich in der Datei /etc/apache2/sites-available/000-default.

den Alias

Alias /owncloud/ /var/www/html

angelegt. Und anschließend mit service apache2 reload den Server neu gestartet bzw angewiesen die Konfigurationsdateien neu zu laden.

Jemand eine Idee?

 

[haydibe]

Webstation hat eigentlich nichts mit dem Zugriff auf die Docker-Container zu tun, ausser die Webstation arbeitet als revese-proxy mit rewrite rules (geht das überhaupt mit der Webstation?!)

Durchstich vom Docker-Container zum Host:
- Volumes: Docker kann nur auf lokal Verzeichnis zugreiffen die gemapped sind. Kein Mapping=Keine Zugriff.
- Port: hier ist relevant nur die lokalen Ports anzupassen und die Container-Ports möglichst nicht zu verändern.

Ich bin mir sicher irgendwo auf Dockerhub unter "caveats" gelesen zu haben, dass ein Nachteil ist, dass der Container während der Einrichtung auf Port 80 horchen muss!

Sonst kannst Du gerne Deine Docker-Konfiguration exportieren und hier als Anhang ranhängen. Dann schaue ich es mir gerne an. Sollte man passwörter oder sonstige personalisierte Werte darin finden, dann bitte diese unkenntlich machen.

Was hast Du mit dem Alias vor? Dir ist klar, dass der nur relativ zu http://dsm-ip:docker-container-port greift oder?
Wenn Du einen reverse-proxy verwenden willst, werden durch den Alias die rewrite-rules natürlich einfacher.

 

[haydibe]

Ich denke ich schau mir mal einen anderen Container an. Der nächst bessere scheint interessant zu sein.

Das Docker-Image sieht deutliche komfortabler aus (Letsencrypt-, mysql- und SSL-Support OOTB) - leider fehlt auch hier die Möglichkeit die UID:GID zu setzen.

Wenn Du komfortabel mit git und docker build bist, dann könntest Du dir die Version von Linuxserver.io anschauen: https://github.com/linuxserver/docker-owncloud
Die Linuxserver.io Images sind meistens solide: sie haben nicht das [URL="https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/"Zobmie Reaping Problem[/URL] und UID:GID sind konfigurierbar. Dies meisten Container verwenden sogar Autoupdate für die Anwendung (bei jedem Neusteart des Containers) ohne das ein Update des Containers stattfinden muss. Der einzige Nachteil: es sind nicht immer die kleinst möglichen Docker-Images.

 

[mdawid]

Hi,

danke erst mal für die Hinweise. Das mit den Volumes habe ich jetzt in den Griff bekommen, indem ich die UID auf der DS angepasst habe. Das ist keine schöne Lösung, aber zum Testen wird es erst mal reichen. Das Docker-Image von l3iggs basiert leider auf Arch-Linux. Auf den ersten Blick konnte ich mich darin nicht so gut wiederfinden.

Das Docker-Image von Linuxserver.io ist für den Anfang vielleicht zu viel, zu mal ich mit docker build und git noch nie was gemacht habe. Sicherlich aber was für die Zukunft zum reinschnuppern .

Was hast Du mit dem Alias vor? Dir ist klar, dass der nur relativ zu http://dsm-ip:docker-container-port greift oder?

Ich wollte die Instanz später unter meinedomain.de/owncloud laufen lassen.

Wenn Du einen reverse-proxy verwenden willst, werden durch den Alias die rewrite-rules natürlich einfacher.

Mit Reverse-Proxies habe ich bis jetzt noch nicht viel gemacht.

Danke und Grüße,

Michael

 

[haydibe]

Ich wollte die Instanz später unter meinedomain.de/owncloud laufen lassen.
,,

Mit Reverse-Proxies habe ich bis jetzt noch nicht viel gemacht.

Genau den wirst Du brauchen
Die gute Nachricht: in DSM6 kann man den Nginx-Webserver für einfache Szenarien komfortabel konfigurieren
Dir schlechte Nachricht: in deinem Fall wirst Du das wohl über eine SSH-Shell lösen müssen.

Lies einfach mal folgenden Thread .