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:
@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.
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.
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?
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.
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.
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.
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…
