Nextcloud-Umzug Berechtigungsproblem

Hallo zusammen,

ich möchte eine Nextcloud von einem V-Server auf einen eigene Maschine umziehen. GrundsĂ€tzlich ist das mit den ganzen Anleitungen ja kein Problem (wenn ich nicht im folgenden noch einen Denkfehler habe), aber ich scheitere an den Verzeichnisrechten. Ich habe die Verzeichnisse ĂŒberspielt (also Datenverzeichnis und das eigentliche Nextcloud-Verzeichnis auf dem alten Server gezippt, auf dem neuen dann entpackt). Auf dem neuen liegt das Datenverzeichnis nun auf einen großen externen Platte.

Nach dem Entpacken liegen die Rechte bei root (und sollten natĂŒrlich am Ende aber wieder auf www-data beschrĂ€nkt sein). Aber weder als root noch nach Änderung auf www-data kann ich auf die Inhalte der beiden Verzeichnisse zugreifen. Was mache ich falsch bzw. muss ich noch anpassen? Die Umzugsanleitungen sagen dazu ja nichts aus, und eine weitere Suche hat mich auch nicht wirklich weitergebracht


(Auch wenn es jetzt kein originÀres Nextcloud-Problem ist hoffe ich, dass jemand hier einen Tipp hat, wo mein Fehler liegt
)

Paraktisch mĂŒsste man halt wissen, welche Anleitungen du verwendest hast, um zu sehen ob es tatsĂ€chlich kein Problem ist. Ich empfehle die offizielle Dokumentation zu nutzen. Hast du alle Punkte, die darin aufgeglistet sind abgearbeitet, insbesondere auch Punkt 3?

Wie hast du die Verzeichnisse ĂŒberspielt? Wenn du z.B. rsync verwendest, solltest du das -a respektive –archive flag verwenden, dann behĂ€lt er die Berechtigungen, die Timestamps usw


Wenn es tatsÀchlich an den Dateiberechtigungen liegt, kannst du die folgendermassen korrigieren:

chown -R www-data:www-data /var/www
chown -R www-data:www-data /var/nextcloud-data
find /var/nextcloud-data/ -type d -exec chmod 750 {} \;
find /var/nextcloud-data/ -type f -exec chmod 640 {} \;
find /var/www/html/nextcloud/ -type d -exec chmod 750 {} \;
find /var/www/html/nextcloud/ -type f -exec chmod 640 {} \;

Anmerkung: Pfade entsprechend anpassen; und allenfalls auch den User, falls du eine Distro verwendest, die nicht Debian/Ubuntu basiert ist.

@Cryx
Vielleicht kannst du ein paar mehr Details mitteilen, wie z. B. die korrekten Dateirechte. Vielleicht ist ja auch nur die externe Festplatte mit dem falschen Dateisystem formatiert. Poste Ausgaben von Befehlen wie z. B. ls -l, poste Fehlermeldungen aus Logdateien und beschreibe korrekt das fehlerhafte Verhalten.

Die externe Platte ist ext4 formatiert


Ich glaube, ich habe mich verwirren lassen, kann aber erst heute Abend zuhause weiter schauen. Auf dem V-Server war es mit den Rechten nĂ€mlich so, dass ich ĂŒberall hinkam. Auf dem neuen Server war das nun Licht möglich. Auf dem V-Server war ich allerdings als root angemeldet, auf dem neuen nur als Nutzer, der halt entsprechende Rechte als, admin hat (sprich: der erste angelegte Benutzer). Eine Testinstallation von Nextcloud, die problemlos lĂ€uft, hat nĂ€mlich die gleichen Rechte. Insofern liegt es hier vermutlich nur an den Anmeldearten und sollte sonst laufen - und ob es das tut habe ich angesichts der unklaren Rwchtesituation noch nicht probiert gehabt.

Alter und neuer Server sind beide Ubuntu, der alte 18, der neue 22.04.

Ich werde heute Abend die Rechte noch mal wie oben setzen, und denke, dass es funktionieren wird. Ich werde berichten - Danke schon mal.

Nur noch mal eine VerstÀndnisfrage - insbesondere weil es bei den Rechten hier nun Unterschiede zwischen meiner Testcloud (die ich zum testen halt auf dem Rechner frisch aufgesetzt hatte) und dem oben beschriebenen nun doch Unterschiede gibt:

Die Testcloud hat 755 fĂŒr Verzeichnisse und 644 fĂŒr Dateien - wie gesagt nach einer Standard-Neuinstallation. Damit komme ich unproblematisch auf alle Verzeichnisse usw.
FĂŒr die umzuziehende Nextcloud war das auf dem alten Server (auch auf dem mal komplett neu aufgesetzt gewesen ohne weitere Anpassung der Rechte) ebenso.

Wenn ich nun 750 bzw 640 setze komme ich nicht in die Verzeichnisse und kann somit auch die Anpassungen in der config.php nur machen, indem ich per sudo ĂŒber den kompletten Pfad die Datei aufrufe.

Wenn 750 bzw. 640 ausreichend ist wĂ€re das wohl aus SicherheitsgrĂŒnden besser, aber verwaltungstechnisch etwas blöde (oder liegt es dann dran, dass ich nur als User mit Root-Rechten im Terminal angemeldet bin und nicht direkt als root?).

Was ist denn fĂŒr den Benutzer und die Gruppe fĂŒr die Dateien angegeben. Korrekt wĂ€re als Benutzer www-data und als Gruppe www-data bei einem Debian/Ubuntu-basierten System. Bitte prĂŒfe das und poste mal z. B.

ls -l /pfad/zur/nextcloud/config/config.php

Unter der Annahme, dass dort www-data:www-data fĂŒr Benutzer und Gruppe steht, so versuchst du wohl mit deinem normalen Benutzer (fĂ€llt in other und damit 0) an den Dateien zu Ă€ndern. Das darfst und sollst du auch nicht. Somit alles in Ordnung, wenn du z. B. sudo aber am besten auf www-data durchfĂŒhrst.

Zum Update nutzt du vielleicht als root folgendes:
sudo -u www-data php /pfad/zur/nextcloud/updater/updater.phar
Daher zum Editieren auch als root:
sudo -u www-data vim /pfad/zur/nextcloud/config/config.php

Dein normaler Benutzer darf weder die genannten Dateien direkt bearbeiten noch direkt per sudo als Benutzer www-data etwas ausfĂŒhren. Könntest du jedoch konfigurieren, wĂ€re eine andere Geschichte. Somit musst du egal wie den Umweg ĂŒber root gehen.

Tipp:
Ich fĂŒr meinen Fall installiere auf dem Webserver außerhalb des virtuellen Nextcloud-Webservers zusĂ€tzlich einen webbasierten Dateimanager wie z. B. Tiny File Manager, wo ich aber immer aus SicherheitsgrĂŒnden die integrierte Benutzerverwaltung deaktiviere und dafĂŒr .htaccess verwende. Vorteil ist, dass dieser natĂŒrlich ĂŒber den Browser als www-data lĂ€uft und somit z. B. auch die Konfigurationen von Nextcloud Ă€ndern kann.

1 Like

Ist alles auf www-data:www-data. Und Sicherheit insofern wie vermutet, okay.

Was mich aber dann dennoch irritiert dass ich regulĂ€r per sudo ohne konkrete Usernennung per -u ĂŒber den Pfad an die config.php komme, wenn das eigentlich nicht sein soll. Oder war sudo mit -u www-data auszufĂŒhren nun nur eine Empfehlung?

Das mit dem Tipp könnte auch eine Lösung sein, warum das auf dem V-Server ging, auf dem lÀuft Plesk als VerwaltungsoberflÀche und ist somit auch webbasiert.

Bleibt fĂŒr mich nur noch die Frage, ob ich dann bei der Installation der Testcloud auf dem neuen Rechner die Rechte nach der Installation hĂ€tte anpassen mĂŒssen - das vorhandene 755/644 ist vermutlich Standard?

755/644 ist etwas unsicherer als 750/640 weil dann halt jeder Benutzer und damit auch jeder Service, der auf deinem Server lÀuft, Lesezugriff auf die Nextcloud Verzeichnisse und Dateien hat. Betreffend der FunktionlitÀt der Nextcloud sollte das aber keinen Unterschied machen.

Ich habe aber immer noch MĂŒhe zu verstehen was ĂŒberhaupt dein eigentliches Problem ist, bzw. was denn genau nicht funktioniert, und wieso du denkst, dass falsche Berechtigungen dieses “Problem” verursachen.

Du kannst auch mit sudo -s oder sudo -i in eine Root Shell wechseln, damit du nicht vor jeden Befehl ein sudo setzen musst, oder du lÀsst es halt auf 744 und 644.

Aber warum sollte man denn ĂŒberhaupt andauernd (egal mit welchem Nutzer) direkt an die Nextcloud Verzeichnisse und Dateien ran mĂŒssen?

1 Like

Naja wenn du sudo ohne “-u www-data” nutzt, dann editierst du als root, da das der Default-Ziel-User bei sudo ist. Wenn du “-u www-data” angibst, dann editierst du als www-data. NatĂŒrlich darf root die Datei editieren. Daher funktioniert das auch. Beim Editieren ist das evtl. auch noch kein Problem. Ein Problem werden irgendwelche Kopien, wo es dann nicht mehr www-data, sondern root gehört.

Was Standard ist, weiß ich gerade gar nicht. Wie @bb77 schreibst ist das eigentlich mit 4 bzw. 5 fĂŒr other kein Problem, da es ja meistens sowieso nur noch dich und als relevanten Benutzer gibt und Angriffe sowieso direkt gegen die Services von www-data laufen. Aber mit 4 bzw. 5 kannst du auch nur lesen und nicht editieren.

Genau, und deshalb verstehe ich das Problem nicht.

Muss man die config.php editieren, nutzt man halt

sudo -u www-data nano /pfad/zur/nextcloud/config/config.php

oder einfach

sudo nano /pfad/zur/nextcloud/config/config.php


was die Dateberechtigungen und Besitzer nicht Àndert bei bestehnden Dateien.

Und viel mehr hat man normalerweise eigentlich auch nicht zu tun im Nextcloud Ordner. :wink:

@Cryx Wenn dir diese Befehle zu lang sind, um sie jedesmal einzutippen, kannst du dir ein Bash Alias dafĂŒr einrichten.

Kleine Anmerkung dazu:

Der Befehl funktioniert als root und in der Regel nicht als normaler Anwender, da sehr wahrscheinlich keine geeignete sudo-Regel hierfĂŒr definiert ist. Also vorher root werden.

Dieser Befehl funktioniert als normaler Benutzer und Àndert die Datei als root. Hierzu muss der Benutzer entsprechend berechtigt sein. Bei Ubuntu ist das eine Standardkonfiguration. Bei Debian muss man das konfiguieren. Teilweise sehen Hoster das aber schon vor.

Von Zeit zu Zeit kann man noch alte von Nextcloud bei Upgrade angefertigte Backups löschen.

Mann kann auch einfach root werden mit sudo -s oder su - und bleiben, in den Ordner gehe und dann als root z. B. mit vim Àndern. Als root kann man auch mit sudo -u www-data -s die IdentitÀt von www-data annehmen und damit arbeiten, falls www-data eine Shell in /etc/passwd definiert hat.

Bei mir funzt das auch mit mmeinem normalen User, und ich habe nichts an der default sudo config geÀndert.

Bei den Cloud Images ist es auch Standard. Bei einer manuellen Installation ab dem ISO, kann man so oder so. LĂ€sst man das Root Passwort leer im Installer, wird sudo automatisch eingerichtet.

Anyways
 Einigen wir uns darauf, dass es auch mit restrektiven Berechtigungen genug Möglichkeiten gibt, root oder www-data zu werden oder Dateien als diese Nutzer anzuschauen oder zu bearbeiten, respektive im Nextcloud Folder zu erledigen was man meint erledigen zu mĂŒssen. :wink:

1 Like

Oh. Dann muss ich das noch mal anschauen bei mir. Kann natĂŒrlich sein, dass die Erlaubnis als root alles auszufĂŒhren dieses inkludiert.

Gerne.

1 Like

Zum Beispiel um Apps zu installieren, die ĂŒber den Nextcloud-Appstote nicht klappen (Mail war da sehr lange ein Kandidat, wo das anders nicht ging).

Das Problem ist bzw. war, dass ich ĂŒber die unterschiedlichen Rechte gestolpert bin, mich gewundert habe und auf Nummer sicher gehen wollte. Hauptverwirrung war hier wohl wirklich fĂŒr mich die Sache mit der WeboberflĂ€che, und der Umstand, dass eine Neuinstallation halt dann andere Rechte hatte (nĂ€mlich auch fĂŒr other).
Insofern ging es mir um das VerstÀndnis, und ich hab wieder was gelernt.

2 Likes

Um das Thema nun mal meinerseits abzuschließen - der Umzug hat geklappt, lĂ€uft alles, auch das neueste Update ist problemlos durchgelaufen.
SchrĂ€g war nur das Ă€ndern des fingerprints, da ich hierfĂŒr die externe Pkatte, auf der das Datenverzeichnis liegt, komplett auf www-data umstellen musste. Hatte ich davor nur fĂŒr das Verzeichnis gemacht, klappte aber nicht. Ist aber auch egal, weil auf die Platte ja nur Nextcloud-Datenverzeichnisse sollen.

Damit also eine kleine Nextcloud umgezogen, am Wochenende folgt nun die grĂ¶ĂŸere.

Danke nochmal fĂŒr die Tipps bzw. die Nachhilfestunde
 :wink:

2 Likes