Hallo,
ich versuche mich gerade an der Nextcloud Installation auf Arch-Linux, welches in einem dedizierten Proxmox LXC Container (also nicht als VM) laufen soll.
Für die Datenbank nutze ich einen separaten Container, in dem PostgreSQL läuft.

Als Webserver soll nginx dienen und php-fpm als Application Server.

Alle meine Server / Dienste wie. z.B. Videoüberwachung sind nur aus dem lokalen Netz bzw. über ein Wireguard VPN erreichbar. Ein direkter Zugriff aus dem Internet heraus ist nicht geplant.

Der "DB" Container ist bereits vollständig lauffähig und auch erreichbar.
Wenn man aus dem Nextcloud Container folgenden Befehl absetzt, wird die Nextcloud Datenbank korrekt eingerichtet und ist auch per psql abfragbar.

occ maintenance:install \
    --database=pgsql \
    --database-name=nextcloud \
    --database-host="DBS.dry.lan" \
    --database-user=nextcloud \
    --database-pass="blablablubb" \
    --admin-pass="blablubb" \
    --admin-email=sysop@dry.lan \
    --data-dir=/zPool/NxCData

Ich denke an das Thema Datenbank kann man daher schon mal einen Haken machen...

Beim Thema Nextcloud Installation tue ich mich dann etwas schwer, zumal der Wiki Artikel einige Dinge nicht beschreibt, bzw. als bekannt voraussetzt. Ich habe aber null Plan von den Themen PHP und NGINX 🙁
Insbesondere das Thema nginx gestaltet sich schwierig, da in dem Nextcloud Wiki Artikel fast nichts dazu steht und auf den nginx Artikel verwiesen wird.

Im Nextcloud Wiki steht zum Thema Rechte ganz lapidar:

Since version 21.0.0 nextcloud more closely follows the web application package guidelines. This introduces the separate user nextcloud, as which the web application is run.

an application server, such as php-fpm or UWSGI is configured to run the web application as the nextcloud user and not the http user

Wenn ich mir nach der Installation des "Nextcloud" Paketes die Rechte im Dateisystem ansehe, dann hat aber alles unterhalb von /usr/share/webapps die Owner root:root.
Also weder "nextcloud" noch "http"!

Daraus würde ich folgern, das entweder die Rechte falsch gesetzt sind, oder an irgendeiner Stelle die Rechte geswitcht werden. Aber wo ist bzw. wo wird das konfiguriert?
Oder fehlt nur ein entsprechender Hinweis im Wiki Artikel, das man das händisch machen muss?

Ok, nachdem ich an dieser Frage hängen geblieben bin, habe ich zunächst einmal nginx gemäß Anleitung installiert.
Um überhaupt mal was testen zu können, habe ich die Muster Konfiguration aus der Anleitung übernommen.

[root@NxC` nginx]# cat nginx.conf
user http;
worker_processes auto;
worker_cpu_affinity auto;

events {
    multi_accept on;
    worker_connections 1024;
}

http {
    charset utf-8;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    server_tokens off;
    log_not_found off;
    types_hash_max_size 4096;
    client_max_body_size 16M;

    # MIME
    include mime.types;
    default_type application/octet-stream;

    # logging
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log warn;

    # load configs
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Außerdem habe ich eine Server Konfiguration gebastelt.

[root@NxC nginx]# cat sites-enabled/OpenWrt.conf 
server {
    listen 80;
    listen [::]:80;
    server_name OpenWrt.dry.lan;
    root /usr/share/webapps/OpenWrt;
    location / {
       autoindex on;
       autoindex_exact_size off;
       autoindex_format html;
       autoindex_localtime on;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name OpenWrt.dry.lan;
    root /usr/share/webapps/OpenWrt;
    location / {
       autoindex on;
       autoindex_exact_size off;
       autoindex_format html;
       autoindex_localtime on;
    }
    ssl_certificate     /etc/ssl/nginx/NxC.dry.lan.crt;
    ssl_certificate_key /etc/ssl/nginx/NxC.dry.lan.key;
}

Zum Test habe ich auch noch einen passenden DNS Eintrag auf meinem OpenWrt "Server" erstellt. Damit ist die Nextcloud Maschine jetzt über 2 DNS Namen erreichbar.

OpenWrt.dry.lan
NxC.dry.lan

Im Ergebnis werden auch alle Dateien & Verzeichniss aus dem Ordner /usr/share/webapps/OpenWrt/ angezeigt.

Dennoch bin ich verwirrt. Im Wiki steht zu nginx:

By default, nginx runs the master process as root and worker processes as user http. To run worker processes as another user, change the user directive in nginx.conf:

In der nginx.conf ist "user=http" spezifiziert. Die Dateien /usr/share/webapps/OpenWrt/ gehören aber alle root:root.
Erst wenn ich einer Datei das Recht für "other" entziehe, wird sie nicht mehr angezeigt!
Müsste man dann nicht grundssätzlich erst einmal allen Dateien in /usr/share/webapps/ diese Rechte entziehen.
Im Wiki habe ich dazu nichts gefunden ...

Und einen Zusammenhang zu "user=http" kann ich sowieso nirgends erkennen.

Ich denke es ist hilfreich bereits an dieser Stelle zu verstehen, was es mit den Dateirechten auf sich hat, bevor ich weiter in die Nextcloud Installation eintauche und totalen Müll produziere ...

Tue dir selbst einen Gefallen und installiere Nextcloud nicht aus den Paketquellen. Früher oder später wirst du damit auf Probleme stossen, die nur umständlich zu lösen sind. Und die Verwirrung mit den Verzeichnisrechten hast du dann auch nicht.

Ja Ich habe ebenso ein RechteProblem Allerdings sagt er bei mir

Fehler

Schreiben in das „apps“-Verzeichnis ist nicht möglich.

Dies kann normalerweise behoben werden, indem dem Webserver Schreibzugriff auf das App-Verzeichnis 
gegeben wird oder der App-Store in der Konfigurationsdatei deaktiviert wird.

bei mir war aber von Haus aus teils root:root rechte als auch nextcloud:nextcloud

Ich bin Jetzt aber etwas verwirrt. Da ich dachte es sei Besser über die Paketquelle es zu verwenden ...

eine andere Möglichkeit wäre es über snapd die Installation zu bewerkstelligen...

teste gerade das mit snapd durch....

Also eine Installation ohne Paketmanager halte ich für absoluten Unsinn.
Damit wird ja das gesamte System früher oder später inkonsistent und man handelt sich zusätzliche Probleme ein ...
Wenn also ein vorhandenes Paket nicht korrekt funktioniert, oder die eigenen Anforderungen nicht erfüllt, dann muss man eben ein eigenes Paket erstellen. Das kann man dann der Allgemeinheit ja wieder im AUR zur Verfügung stellen.

Und Snap ist (zumindest für mich) keine Alternative. Ich versuche ja gerade mit LXC Containern möglichst leichtgewichtige Installationen zu bekommen. Eine GUI gibts logischerweise auch nicht...
Nach meinen Erfahrungen sind die schlanken Container auch noch deutlich performater als z.B. Docker Container.
Daher habe ich meinen alten "Rechnerzoo" schon weitestgehend entsorgt. Es gibt nur noch einen Proxxmox Server auf dem ein paar Windows VM's laufen (z.B. für WISO, ElsaWin). Ansonsten nur LXC Container, wie z.B. der PostgreSQL DB oder TVHeadend Server.

Leider bilden die Wiki Artikel meißt nur eine einfache Installationsmethode ab. Nämlich alles auf einer Maschine.
Eine klassische (Windows) Desktop Installation halt...

Das Thema Verzeichnisrechte versuche ich (im Zusammenhang mit nginx) gerade zu verstehen.
Dafür erscheint mit nextcloud nicht gerade ideal....

Zunächst einmal ist da nginx mit der nginx.conf. Hier wird festgelegt, mit welchem User die Workprozesse von nginx laufen. Wenn man ausschließlich die Konfigurationsdateien nginx.conf und OpenWrt.conf aus meinem obigen Beitrag nimmt, dann stellt man fest, das Daten aus dem Verzeichnis /usr/share/webapps/OpenWrt ausgeliefert werden.
Da auf /usr/share/webapps/OpenWrt üblicherweise auch Rechte für "other" existieren, ist es fast völlig egal, was man in der nginx.conf konfiguriert.
Erst wenn man die Rechte für other vollständig entzieht (# chmod -R o-rwx /usr/share/webapps/OpenWrt/) merkt man, was Sache ist. Das steht leider nicht explizit im Wiki.
Jetzt plötzlich wird nämlich nur noch dann etwas ausgeliefert, wenn der user oder die group mit den in der nginx.conf angegebenen user=http übereinstimmt.

Bis hierhin hat man auch noch nichts mit PHP oder gar PHP-FPM zu tun. Es handelt sich ja nur um statische Inhalte.
Das wird dann der nächste Punkt sein, den ich verstehen möchte ....

    Wie in der Anleitung beschrieben habe ich Konfiguration aus nextcloud.conf in das Verzeichnis /etc/nginx/sites-available/nextcloud.conf kopiert.
    Dann den "upstream php-handler" Block entfernt und im Block "location ~ .php(?:$|/) {" die folgende Zeile hinzugefügt.
    fastcgi_pass unix:/run/php-fpm/nextcloud.sock;
    Schließlich habe ich noch root und Server-Namen angepasst.
    root /user/share/webapps/nextcloud;
    server_name NxC.dry.lan;

    Ich dachte mit einem Neustart von nginx und php-fpm sei die Sache erledigt. Weit gefehlt ...

    Nachdem ich in meinem jugendlichen Leichtsinn versucht habe die https://NxC.dry.lan/ aufzurufen passierte .... nichts.

    Da ich keinen Plan hatte was da denn überhaupt passiert, war meine Idee zunächst eine phpinfo.php zu erstellen, die mir Auskunft zu PHP geben sollte.
    <?php
    echo str_replace("\n", '<br>', shell_exec('ps -u -p '.getmypid()));
    echo '<br/>Script owner: '.get_current_user();
    echo ' / UID: '.getmyuid();
    echo '<br/>GID: '.getmygid();
    echo '<br/>';
    $groupid = getmygid();
    $groupinfo = posix_getgrgid($groupid);
    print_r($groupinfo);
    ?>

    Aber der Aufruf https://NxC.dry.lan/phpinfo.php verlief ebenfalls ohne Reaktion. Was ist da los?

    Im Verzeichnis /usr/share/webapps/nextcloud/ existiert eine index.html die ihrerseits dann eine index.php aufruft. Gut, aber ich hatte ja die phpinfo.php aufgerufen ...

    Nach etwas herumstochern habe ich dann herausbekommen, das in der oben genannten nextcloud.conf ein "rewrite" Befehl existiert. Dieser verhindert zuverlässig, den Aufruf meiner phpinfo.php!
    Also die original index.php gesichert und die phpinfo.php in index.php umbenannt.

    Zusätzlich habe ich mir die /etc/php/php-fpm.d/nextcloud.conf angesehen. Es gibt dort Parameter für user, listen.user, group und listen.group.

    Wenn ich die Doku richtig verstanden habe, dann sind die "listen." Variablen diejenigen, über die die Rechte des sockets gesetzt werden.
    Eingetragen sind listen.user=nextcloud und listen.group=http.
    Das würde bedeuten, das die Rechte entsprechend zu setzen sind.
    chown -R nextcloud:http /usr/share/webapps/nextcloud/

    Und siehe da mein phpinfo.php script liefert tatsächlich eine Ausgabe.

    Ich habe daraufhin eine ganze Reihe von Berechtigungs-Kombinationen getestet. Die Ergebnisse habe ich hier mal aufgelistet. Allerdings verwirren sie mich eher, als das sie mir helfen zu verstehen ....

    `user = nextcloud
    group = nextcloud
    listen.owner = nextcloud
    listen.group = nextcloud
    chown -R http:http nextcloud/ -> 502 bad gateway
    chown -R nextcloud:http nextcloud/ -> 502 bad gateway
    chown -R http:nextcloud nextcloud/ -> 502 bad gateway
    chown -R nextcloud:nextcloud nextcloud/ -> 404 Not Found nginx

    user = nextcloud
    group = nextcloud
    listen.owner = http
    listen.group = http
    chown -R http:http nextcloud/ -> File not found
    chown -R nextcloud:http nextcloud/ -> ok
    chown -R http:nextcloud nextcloud/ -> ok
    chown -R nextcloud:nextcloud nextcloud/ -> 404 Not Found nginx

    user = nextcloud
    group = nextcloud
    listen.owner = nextcloud
    listen.group = http
    chown -R http:http nextcloud/ -> File not found
    chown -R nextcloud:http nextcloud/ -> ok
    chown -R http:nextcloud nextcloud/ -> ok
    chown -R nextcloud:nextcloud nextcloud/ -> 404 Not Found nginx
    `

    Beim eigentlichen Problem, komme ich auch mit diesen Erkenntnissen keinen Schritt weiter.
    Mit der Original index.php von Nextcloud bekomme ich nämlich diese nichtssagende Fehlermeldung:
    Ihr Datenverzeichnis ist ungültig. Stellen Sie sicher, dass eine Datei ".ocdata" im Wurzelverzeichnis des Datenverzeichnisses existiert. Kann das "Daten"-Verzeichnis nicht erstellen. Dies kann normalerweise behoben werden, indem dem Webserver Schreibzugriff auf das Wurzel-Verzeichnis eingeräumt wird. Siehe auch https://docs.nextcloud.com/server/24/go.php?to=admin-dir_permissions

    Die Datei ist vorhanden, und selbst wenn ich die Rechte in allen Verzeichnissen auf 777 setze, ändert das rein gar nichts 🙁.
    Das was Nextcloud da als Fehlermeldung liefert ist eine absolute Null-Nummer....

    Bei meinen Nextcloud Installationen habe ich - allerdings unter CentOS - folgende Rechte:

    # ls -ldh /var/www/html/nextcloud
    drwxr-x--- 14 root apache 4.0K Mar 23 19:57 /var/www/html/nextcloud

    Beim CentOS Derivat (Nextcloud über Paketmanager installiert) siehts so aus:

    $ ls -ldh /usr/share/nextcloud
    drwxr-xr-x 16 apache apache 4.0K Jul  9 10:39 /usr/share/nextcloud

    fow0ryl Also eine Installation ohne Paketmanager halte ich für absoluten Unsinn.
    Damit wird ja das gesamte System früher oder später inkonsistent und man handelt sich zusätzliche Probleme ein ...

    Im allgemeinen gebe ich dir Recht. Nextcloud allerdings läuft ja sytemunabhängig und bring seinen internen Updater mit. Die Nextcloud-Apps werden auch intern installiert und aktualisiert. Daher gibts da kein Problem mit Inkonsistenzen oder andere Probleme.
    Der Update-Prozess über den Paketmanager bringt mir zwar auch immer das Problem, dass ich die trusted domains jedesmal wieder um meine dyndns-Adresse ergänzen muss, aber das ist weniger Arbeit als der Nextcoud eigene Updateprozess. Der klappt eigentlich nie ohne dass ich Nextcloud seperat runterlade und ins Downloadverzeichnis schiebe

    • fow0ryl hat auf diesen Beitrag geantwortet.

      Josephus Miller Die Nextcloud-Apps werden auch intern installiert und aktualisiert. Daher gibts da kein Problem mit Inkonsistenzen oder andere Probleme.

      Die Installation der Apps über den Nextcloud Updater kann ich mir durchaus vorstellen. Zumal man dafür in Nextcloud ja auch noch dedizierte Rechte vergeben kann.
      Aber die Basis Installation hängt von vielen anderen Dingen ab. Z.B. der PHP-Version und auch der Datenbank ab.
      Wenn man nun auf einem System PHP als Abhängigkeit zu anderer Software installiert hatte, kann es zu Problemen nach einem Systemupdate kommen.
      Dann weiß nämlich nach einer Installation unter Umgehung des Paket Managers das System nichts von Nextcloud und umgekehrt.
      Und es hat Bum gemacht ....
      So geschen, als Arch Linux von PHP7 auf PHP8 als default gewechselt hat und zu Fuß installiertes Software noch auf PHP7 angewiesen war.

      Eine Kombination aus Nextcloud Updater und System-Paketmanager kann unter bestimmen Voraussetzungen durchaus sinnvoll sein. Nur eben ganz außerhalb des Paketmanagers halte ich für fragwürdig.

      • krisz hat auf diesen Beitrag geantwortet.

        fow0ryl So geschen, als Arch Linux von PHP7 auf PHP8 als default gewechselt hat und zu Fuß installiertes Software noch auf PHP7 angewiesen war.

        Das über pacman installierte nextcloud hatte beim Versionswechsel von PHP auch Probleme, da es noch auf PHP7 angewiesen war. Ich hatte es damals nicht hinbekommen, beide PHP-Versionen parallel zu konfigurieren und konnte ein paar Wochen kein vollständiges Systemupdate durchführen.

        Das Hauptproblem ist wie hier Teils angesprochen dass Nextcloud schlicht inkompatibel mit Rollingrelease ist.

        Ich hab eine ganze Zeit versucht Nextcloud unter Archlinux zum laufen zu bringen bzw zu halten.

        Selbst wenn man das nach Tagen des rum frickelns zum laufen bringt, hält das nur einige Zeit/Updates bis Nextcloud wieder ausfällt weil es mit aktuellen Paketen nicht klar kommt.

        Das PHP Thema hat mich dazu gebracht das Thema unter Archlinux abzuhaken, und betreibe Nextcloud über NextcloudPI auf einem RaspberryPi 4. Nicht so performant, aber es läuft ohne ständig in die Software und dem Betriebssystem eingreifen zu müssen.

        Auch Installationen unter Debian oder Ubuntu laufen nur zuverlässig, wenn man nicht allzu oft Updates ausführt.
        Da auch hier die verschiedenen notwendigen Komponenten unterschiedlichen Release-Zyklen unterliegen ....
        Ich bin unter Debian letztlich auch gescheitert, da irgendeine Komponente zwingend PHP8 benötigte. Nextcloud aber noch auf PHP7 angewiesen war.

        Diese Abhängigkeiten haben mich letztlich dazu gebracht, alles unter Proxmox in LXC Container zu installieren.
        Für jeden Dienst gibt es eine eigenen Instanz. Auf dem Datenbank Container läuft nur PostgreSQL. Auf dem TVHeadend Server nur TVHeadend. Und NextCloud wird es demnächst auch in einer eigenen Instanz geben.
        Daneben gibts noch Instanzen für Homegear, Manjaro LxQt, und VM's für WISO, ElsaWin
        Damit sind die Abhängigkeiten immer nur in einer Instanz vorhanden und somit im Gegensatz zu einer klassischen Desktop/AllinOne Installation recht gering.
        Gleichzeitig ist der Overhead durch die LXC Container im Gegensatz zu einer Docker oder gar VM Variante total vernachlässigbar.

        Wenn man dann vor jedem Update einen Snapshot (auf BTRFS bzw. ZFS) zieht, kann man ruhigen Gewissens ein Update ausführen. Gibts Probleme ist man mit einem Rollback innerhalb von Sekunden wieder auf dem alten Stand.
        Dann kann man das gesamte System innerhalb von Sekunden clonen und im Clone nach Fehlern suchen.

        Das mache ich während meiner Installationsversuche von Nextcloud genau so. Nach jedem Schritt ein Snapshot.
        Funktioniert etwas nicht. Rollback und gut.
        Oder von einem beliebigen Snapshot einen Clone erzeugt und von dort aus einen anderen Installationsweg beschritten.

        Das Einzige was man dazu benötigt ist ein halbwegs leistungsfähiger Rechner mit etwas mehr RAM.
        Wenn man ZFS nutzen möchte, darf es auch etwas mehr mehr sein.
        Ich nutze hier ein System mit einem Ryzen 5500G, 32GB RAM, 4 HDD's mit je 4TB, 2 NVME SSD's mit je 1TB, 2 DVB-S2 Tuner Karten. Obendrein spare ich sogar noch Energie. Das System braucht im 24h Betrieb durchschnittlich nur knapp 40W/h.
        Das ist wesentlich weniger als die zuvor notwendigen RaspI 4 (2*) , die ganze DVB-S2 Hardware inkl. Mulitswitch, der Freifunk Router und das Intel-basierte NAS.

        Kann ich nur jedem, der etwas mehr bastelt, empfehlen !

        Mit Nextcloud bin ich wieder ein Stück weiter gekommen...

        Ein Blick in "/var/log/nextcloud/nextcloud.log" förderte einige Meldungen zu Tage, in denen etwas mit "open_basedir" angemeckert wurde. Auch hier musste ich wieder recherchieren, da ich keine Ahnung hatte was das denn zu bedeuten hat. Im Arch Linux - NextCloud Wiki hatte ich zwar gelesen, das man diese Variable zur Verbesserung der Security nutzen könne. Hab ich aber nicht ...

        Ich hatte "nur" die im Wiki genannte functional config kopiert. Und siehe da, dort fand sich ein open_basedir Eintrag.

        Dummerweise funktioniert der nur, wenn man kein eigenes Datenverzeichnis nutzt!
        Wenn "open_basedir" gesetzt ist, dann müssen alle genutzten Verzeichnisse dort definiert sein. Ich musste also das Datenverzeichnis hinzufügen. Bei mir lautet das /zPool/nextcloud
        Aber Achtung! Man darf das Verzeichnis nicht mit einem "/" abschließen, wenn der Eintrag auch für Unterverzeichnisse gelten soll.


        php_value[open_basedir] = /var/lib/$pool:/var/lib/$pool/apps:/tmp:/usr/share/webapps/$pool:/etc/webapps/$pool:/dev/urandom:/usr/lib/php/modules:/var/log/$pool:/proc/meminfo:/zPool/nextcloud

        In der Folge habe ich dann festgestellt, das für das Datenverzeichnis und dessen Unterverzeichnisse abweichende Berechtigungen notwendig sind, bzw. z.B. beim Einrichten eines neuen Users automatisch abweichend gesetzt werden.
        Bei mir wäre das:
        chmod -R nextcloud:nextcloud /zPool/nextcloud/

        Zu beachten ist außerdem das im php-fpm service overlay die "richtigen" Pfade angegeben sind. Ansonsten läßt sich php-fpm gar nicht starten
        [Service]
        ExecStart=
        ExecStart=/usr/bin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf --php-ini /etc/php/php-fpm.ini
        ReadWritePaths=/zPool/nextcloud
        ReadWritePaths=/var/lib/nextcloud
        ReadWritePaths=/usr/share/webapps/nextcloud
        ReadWritePaths=/etc/webapps/nextcloud/config