Das Problem: Beim Versuch, auf die App zuzugreifen (auch beim ersten Mal), erhalte ich die Fehlermeldung „404 - Datei nicht gefunden“.

Question

Das Problem: Beim Versuch, auf die App zuzugreifen (auch beim ersten Mal), erhalte ich die Fehlermeldung „404 - Datei nicht gefunden“.

Beim Versuch, über nextcloud.example.com in einem Browser auf die App zuzugreifen, erhalte ich diesen Fehler aus dem Konsolenprotokoll des NextCloud FMP Docker-Containers:

172.19.0.5 -  04/Mar/2023:22:36:01 +0000 "GET /index.php" 404

Und dieser Fehler aus dem Konsolenprotokoll des NGinX Docker-Containers:

172.69.67.108 - - [04/Mar/2023:22:36:01 +0000] "GET / HTTP/2.0" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"

Die Einrichtung des Docker Server Hosts und der Container

1. Docker Host Server-Betriebssystem ist Ubuntu 22.04 LTS

2. NGinX Docker Container. Mir ist bewusst, dass eine docker-compose.yml am besten ist, aber im Moment und bis ich das richtig zum Laufen bekomme, führe ich den Container mit Folgendem aus:

   docker run -p 80:80 -p 443:443 --name nginx \
       --restart=unless-stopped \
       -v certbot:/etc/letsencrypt \
       -v nginx:/etc/nginx/conf.d \
       -v www:/usr/share/nginx/html \
       --network tools \
       -d nginx
   

   Dies ist der einzige Container auf dem Docker-Server-Host mit freigegebenen Ports und verwendet Volume-Mounts zum Teilen von:

   • Zertifikate mit einem CertBot-Container
   • NGinX Conf-Verzeichnis zum Einrichten einer Conf für jede App
   • HTML-Www-Stammverzeichnis zur Freigabe mit dem NextCloud FPM Docker Container
   • Netzwerk-Tools

3. NextCloud FPM Docker Container, ich führe den Container aus mit:

   docker run --name nextcloud-fpm \
       --restart=unless-stopped \
       -v www:/var/www/html \
       -e 'TRUSTED_PROXIES=nginx' \
       -e 'POSTGRES_HOST=database.server.com' \
       -e 'POSTGRES_USER=database_user' \
       -e 'POSTGRES_PASSWORD=database_user_password' \
       -e 'POSTGRES_DB=databse_name' \
       --network tools \
       -d nextcloud:fpm
   

   Dieser Container wird auf denselben Netzwerktools ausgeführt, damit die Ports der App nicht dem Docker-Hostserver zugänglich gemacht werden müssen und um die Erstellung der Container-Stacks und der NGinX-Konfigurationsdatei zu vereinfachen, indem für Proxy-Reverses die Containernamen anstelle von IPs verwendet werden.

   • HTML-WWW-Stammverzeichnis zur Freigabe mit dem NGinX-Docker-Container
   • Umgebungsvariablen für vertrauenswürdigen Proxy (den NGinX-Container
   • Umgebungsvariablen für PostgreSQL-Datenbank
   • Dieser Cotainer betreibt FPM auf Port 9000
   • Netzwerk-Tools

4. NGinX-Conf-Dateien, es gibt zwei davon, eine default.conf, die hauptsächlich verhindert, dass der Host-Server direkt über IP und Port erreicht werden kann (Beispiel xxx.xxx.xxx.xxx:80 oder xxx.xxx.xxx.xxx:443):

   server {
       # Removes Web Server Info
       server_tokens off;
       # HTTP
       listen      80 default_server;
       listen [::]:80 default_server;
       listen      443 ssl http2 default_server;
       listen [::]:443 ssl http2 default_server;
       ssl_reject_handshake on;
       # Identify Server without the name, hence just IP
       server_name _;
       # Return Empty Response
       return 444;
   }
   

   Zum Schluss noch die nextcloud.conf, sie wurde übernommen ausOffizielles GitHub NextCloud FPM-Repo:

   upstream php-handler {
       server nextcloud-fpm:9000; # In here I set up the Stream with the NextCloud FPM Container name
   }
   
   server {
   listen 80;
   listen [::]:80;
   server_name nextcloud.example.com;
   
   return 301 https://$server_name$request_uri;
   }
   
   server {
   listen 443 ssl;
   listen [::]:443 ssl;
   server_name nextcloud.example.com;
   
   ssl_certificate /etc/letsencrypt/live/nextcloud.example.com/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/nextcloud.example.com/privkey.pem;
   
       # HSTS settings
       # WARNING: Only add the preload option once you read about
       # the consequences in https://hstspreload.org/. This option
       # will add the domain to a hardcoded list that is shipped
       # in all major browsers and getting removed from this list
       # could take several months.
       #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
   
       # set max upload size
       client_max_body_size 512M;
       fastcgi_buffers 64 4K;
   
       # Enable gzip but do not remove ETag headers
       gzip on;
       gzip_vary on;
       gzip_comp_level 4;
       gzip_min_length 256;
       gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
       gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/>
       # Pagespeed is not supported by Nextcloud, so if your server is built
       # with the `ngx_pagespeed` module, uncomment this line to disable it.
       #pagespeed off;
   
       # HTTP response headers borrowed from Nextcloud `.htaccess`
       add_header Referrer-Policy                      "no-referrer"   always;
       add_header X-Content-Type-Options               "nosniff"       always;
       add_header X-Download-Options                   "noopen"        always;
       add_header X-Frame-Options                      "SAMEORIGIN"    always;
       add_header X-Permitted-Cross-Domain-Policies    "none"          always;
       add_header X-Robots-Tag                         "none"          always;
       add_header X-XSS-Protection                     "1; mode=block" always;
   
       # Remove X-Powered-By, which is an information leak
       fastcgi_hide_header X-Powered-By;
   
       # Path to the root of your installation
       root /usr/share/nginx/html/; # Since NGinX is the Web Server, I am pointing root to where the NextCloud Files are mounted inside the NGinX Container from the NextCloud FPM Container
   
       # Specify how to handle directories -- specifying `/index.php$request_uri`
       # here as the fallback means that Nginx always exhibits the desired behaviour
       # when a client requests a path that corresponds to a directory that exists
       # on the server. In particular, if that directory contains an index.php file,
       # that file is correctly served; if it doesn't, then the request is passed to
       # the front-end controller. This consistent behaviour means that we don't need
       # to specify custom rules for certain paths (e.g. images and other assets,
       # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
       # `try_files $uri $uri/ /index.php$request_uri`
       # always provides the desired behaviour.
       index index.php index.html /index.php$request_uri;
   
       # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
       location = / {
           if ( $http_user_agent ~ ^DavClnt ) {
               return 302 /remote.php/webdav/$is_args$args;
           }
       }
   
       location = /robots.txt {
           allow all;
           log_not_found off;
           access_log off;
       }
   
       # Make a regex exception for `/.well-known` so that clients can still
       # access it despite the existence of the regex rule
       # `location ~ /(\.|autotest|...)` which would otherwise handle requests
       # for `/.well-known`.
       location ^~ /.well-known {
           # The rules in this block are an adaptation of the rules
           # in `.htaccess` that concern `/.well-known`.
   
           location = /.well-known/carddav { return 301 /remote.php/dav/; }
           location = /.well-known/caldav  { return 301 /remote.php/dav/; }
   
           location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
           location /.well-known/pki-validation    { try_files $uri $uri/ =404; }
   
           # Let Nextcloud's API for `/.well-known` URIs handle all other
           # requests by passing them to the front-end controller.
           return 301 /index.php$request_uri;
       }
   
       # Rules borrowed from `.htaccess` to hide certain paths from clients
       location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
       location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }
   
       # Ensure this block, which passes PHP files to the PHP process, is above the blocks
       # which handle static assets (as seen below). If this block is not declared first,
       # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
       # to the URI, resulting in a HTTP 500 error response.
       location ~ \.php(?:$|/) {
           # Required for legacy support
           rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;
   
           fastcgi_split_path_info ^(.+?\.php)(/.*)$;
           set $path_info $fastcgi_path_info;
   
           try_files $fastcgi_script_name =404;
   
           include fastcgi_params;
           fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
           fastcgi_param PATH_INFO $path_info;
           #fastcgi_param HTTPS on;
   
           fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
           fastcgi_param front_controller_active true;     # Enable pretty urls
           fastcgi_pass php-handler;
   
           fastcgi_intercept_errors on;
           fastcgi_request_buffering off;
       }
   
       location ~ \.(?:css|js|svg|gif)$ {
           try_files $uri /index.php$request_uri;
           expires 6M;         # Cache-Control policy borrowed from `.htaccess`
           access_log off;     # Optional: Don't log access to assets
       }
   
       location ~ \.woff2?$ {
           try_files $uri /index.php$request_uri;
           expires 7d;         # Cache-Control policy borrowed from `.htaccess`
           access_log off;     # Optional: Don't log access to assets
       }
   
       # Rule borrowed from `.htaccess`
       location /remote {
           return 301 /remote.php$request_uri;
       }
   
       location / {
           try_files $uri $uri/ /index.php$request_uri;
       }
   }
   

Was ich bisher versucht habe

1. Mein erster Instinkt bestand darin, die Protokolle zu überprüfen. Ich habe sie zu Beginn dieses Beitrags geteilt. Darauf aufbauend habe ich überprüft, ob die Dateien in beiden Containern vorhanden waren. Dazu habe ich zwei verschiedene Arten verwendet:

   Ich habe einen Portainer-Container, der auf demselben Docker-Host-Server läuft, und auch dahinter den vernünftigen NGinX-Docker-Container als Proxy Reverse. Ich habe eine Konsole angeschlossen und suche nach den Dateien in beiden Containern, was ich auch docker exec container_name -it bashauf beiden Containern gemacht habe:

   NGinX-Container, denken Sie daran, die Halterung war auf/usr/share/nginx/html

   root@61564cff4e67:/# ls -lha /usr/share/nginx/html
   total 180K
   drwxrwxrwx 15 www-data www-data 4.0K Mar  4 13:24 .
   drwxr-xr-x  3 root     root     4.0K Feb  9 04:36 ..
   -rw-r--r--  1 www-data www-data 3.2K Mar  4 13:24 .htaccess
   -rw-r--r--  1 www-data www-data  101 Mar  4 13:24 .user.ini
   drwxr-xr-x 47 www-data www-data 4.0K Mar  4 13:24 3rdparty
   -rw-r--r--  1 www-data www-data  19K Mar  4 13:24 AUTHORS
   -rw-r--r--  1 www-data www-data  34K Mar  4 13:24 COPYING
   drwxr-xr-x 50 www-data www-data 4.0K Mar  4 13:24 apps
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 config
   -rw-r--r--  1 www-data www-data 4.0K Mar  4 13:24 console.php
   drwxr-xr-x 23 www-data www-data 4.0K Mar  4 13:24 core
   -rw-r--r--  1 www-data www-data 6.2K Mar  4 13:24 cron.php
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 custom_apps
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 data
   drwxr-xr-x  2 www-data www-data  12K Mar  4 13:24 dist
   -rw-r--r--  1 www-data www-data  156 Mar  4 13:24 index.html
   -rw-r--r--  1 www-data www-data 3.4K Mar  4 13:24 index.php
   drwxr-xr-x  6 www-data www-data 4.0K Mar  4 13:24 lib
   -rwxr-xr-x  1 www-data www-data  283 Mar  4 13:24 occ
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocm-provider
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs-provider
   -rw-r--r--  1 www-data www-data 3.1K Mar  4 13:24 public.php
   -rw-r--r--  1 www-data www-data 5.5K Mar  4 13:24 remote.php
   drwxr-xr-x  4 www-data www-data 4.0K Mar  4 13:24 resources
   -rw-r--r--  1 www-data www-data   26 Mar  4 13:24 robots.txt
   -rw-r--r--  1 www-data www-data 2.4K Mar  4 13:24 status.php
   drwxr-xr-x  3 www-data www-data 4.0K Mar  4 13:24 themes
   -rw-r--r--  1 www-data www-data  383 Mar  4 13:24 version.php
   

   NextCloud FPM-Container, denken Sie daran, die Halterung war auf/var/www/html

   root@938c95d0e1ae:/var/www/html# ls -lha
   total 180K
   drwxrwxrwx 15 www-data www-data 4.0K Mar  4 13:24 .
   drwxrwxr-x  1 www-data root     4.0K Feb 16 03:06 ..
   -rw-r--r--  1 www-data www-data 3.2K Mar  4 13:24 .htaccess
   -rw-r--r--  1 www-data www-data  101 Mar  4 13:24 .user.ini
   drwxr-xr-x 47 www-data www-data 4.0K Mar  4 13:24 3rdparty
   -rw-r--r--  1 www-data www-data  19K Mar  4 13:24 AUTHORS
   -rw-r--r--  1 www-data www-data  34K Mar  4 13:24 COPYING 
   drwxr-xr-x 50 www-data www-data 4.0K Mar  4 13:24 apps
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 config
   -rw-r--r--  1 www-data www-data 4.0K Mar  4 13:24 console.php
   drwxr-xr-x 23 www-data www-data 4.0K Mar  4 13:24 core
   -rw-r--r--  1 www-data www-data 6.2K Mar  4 13:24 cron.php
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 custom_apps
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 data
   drwxr-xr-x  2 www-data www-data  12K Mar  4 13:24 dist
   -rw-r--r--  1 www-data www-data  156 Mar  4 13:24 index.html
    -rw-r--r--  1 www-data www-data 3.4K Mar  4 13:24 index.php
   drwxr-xr-x  6 www-data www-data 4.0K Mar  4 13:24 lib
   -rwxr-xr-x  1 www-data www-data  283 Mar  4 13:24 occ
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocm-provider
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs
   drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs-provider
   -rw-r--r--  1 www-data www-data 3.1K Mar  4 13:24 public.php
   -rw-r--r--  1 www-data www-data 5.5K Mar  4 13:24 remote.php
   drwxr-xr-x  4 www-data www-data 4.0K Mar  4 13:24 resources
   -rw-r--r--  1 www-data www-data   26 Mar  4 13:24 robots.txt
   -rw-r--r--  1 www-data www-data 2.4K Mar  4 13:24 status.php
   drwxr-xr-x  3 www-data www-data 4.0K Mar  4 13:24 themes
   -rw-r--r--  1 www-data www-data  383 Mar  4 13:24 version.php
   

   Docker-Server-Host-Bind-MountZuletzt muss ich noch die Dateien auf dem Docker-Host-Server selbst überprüfen, da ich nicht nur den gemeinsamen Stammspeicherort für beide Container erreichen möchte, sondern auch über persistente Daten verfügen möchte, falls ich den Container verschieben muss:

   ❯ ll
   total 180K
   drwxrwxrwx 15 www-data  www-data  4.0K Mar  4 13:24 .
   drwxrwxr-x 10 Alejandro Alejandro 4.0K Mar  4 13:24 ..
   drwxr-xr-x 47 www-data  www-data  4.0K Mar  4 13:24 3rdparty
   drwxr-xr-x 50 www-data  www-data  4.0K Mar  4 13:24 apps
   -rw-r--r--  1 www-data  www-data   19K Mar  4 13:24 AUTHORS
   drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 config
   -rw-r--r--  1 www-data  www-data  4.0K Mar  4 13:24 console.php
   -rw-r--r--  1 www-data  www-data   34K Mar  4 13:24 COPYING
   drwxr-xr-x 23 www-data  www-data  4.0K Mar  4 13:24 core
   -rw-r--r--  1 www-data  www-data  6.2K Mar  4 13:24 cron.php
   drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 custom_apps
   drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 data
   drwxr-xr-x  2 www-data  www-data   12K Mar  4 13:24 dist
   -rw-r--r--  1 www-data  www-data  3.2K Mar  4 13:24 .htaccess
   -rw-r--r--  1 www-data  www-data   156 Mar  4 13:24 index.html
   -rw-r--r--  1 www-data  www-data  3.4K Mar  4 13:24 index.php
   drwxr-xr-x  6 www-data  www-data  4.0K Mar  4 13:24 lib
   -rwxr-xr-x  1 www-data  www-data   283 Mar  4 13:24 occ
   drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocm-provider
   drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocs
   drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocs-provider
   -rw-r--r--  1 www-data  www-data  3.1K Mar  4 13:24 public.php
   -rw-r--r--  1 www-data  www-data  5.5K Mar  4 13:24 remote.php
   drwxr-xr-x  4 www-data  www-data  4.0K Mar  4 13:24 resources
   -rw-r--r--  1 www-data  www-data    26 Mar  4 13:24 robots.txt
   -rw-r--r--  1 www-data  www-data  2.4K Mar  4 13:24 status.php
   drwxr-xr-x  3 www-data  www-data  4.0K Mar  4 13:24 themes
   -rw-r--r--  1 www-data  www-data   101 Mar  4 13:24 .user.ini
   -rw-r--r--  1 www-data  www-data   383 Mar  4 13:24 version.php
   
   root@myserver /mnt/Volume/data/www
   

   Ich sehe keinen Grund, warum es hinsichtlich der Berechtigungen nicht funktionieren sollte und habe bestätigt, dass die Dateien wie vorgesehen in allen drei Instanzen vorhanden sind.

2. Prüfen Sie die NGinX-Conf-Datei für NextCloud FPM nextcloud.conf. Nach reiflicher Überlegung denke ich, dass nur etwas falsch sein kann, da ich über die Domäne in einem Browser bis zum NGniX-Webserver-Container gelange, da ich 404-Einträge „Nicht gefunden“ in seinem Protokoll habe und auch von der NextCloud-Containerinstanz selbst eine Antwort „404 Nicht gefunden“ erhalte. Mein einziges Problem hängt also mit dem Root-Eintrag in der Conf-Datei zusammen:

   NextCloud-Protokoll:

   172.19.0.5 -  04/Mar/2023:22:36:01 +0000 "GET /index.php" 404
   

   NGinX-Protokoll:

   172.69.67.108 - - [04/Mar/2023:22:36:01 +0000] "GET / HTTP/2.0" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"
   

   Also habe ich die Root-Direktive in geändert /var/www/htmlund das Verhalten hat sich ein wenig geändert. Ich erhalte noch immer einen 404-Eintrag „Nicht gefunden“, aber nur in den Protokollen des NGinX-Webserver-Containers. Der NextCloud-Container ist stumm, daher erreiche ich ihn mit dieser Änderung nicht:

   NextCloud-Protokoll(leer, kein Eintrag):

   NGinX-Protokoll:

   2023/03/05 00:13:24 [error] 473#473: *4152 "/var/www/html/index.php" is not found (2: No such file or directory), client: 172.69.65.73, server: nextcloud.example.com, request: "GET / HTTP/2.0", host: "nextcloud.example.com"
   172.69.65.73 - - [05/Mar/2023:00:13:24 +0000] "GET / HTTP/2.0" 404 174 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"
   

   Es gibt einen Unterschied im Verhalten des Webservers. Mir ist aufgefallen, dass ich nach der Änderung der Root-Direktive die tatsächliche Domäne im Protokoll in Anführungszeichen sehe, "nextcloud.example.com"während vorher nur ein Bindestrich da war "-".

3. Als Nächstes habe ich einfach die NGinX-Conf-Datei default.conf deaktiviert, da dies der einzige Ort ist, der mir einfällt. Das "-"Ergebnis war dasselbe wie oben und ich habe es in beiden Szenarien 1 und 2 wiederholt. Ich habe es bereits versucht. Es liegt "_"auch an der Serverdirektive der default.conf, war also ein Schuss ins Blaue.

4. Ich habe viele andere Einstellungen mit der Konfiguration ausprobiert, aber bei den meisten waren es am Ende Too Many Redirections, Bad Certificate, oder einfach nur 502Fehler.

Meine Feststellung, was das Problem ist und wo ich feststecke

Es scheint, dass ich meinem gewünschten Ergebnis sehr nahe bin, da ich beide Container von Browsern mit der gewünschten Domäne aus erreiche und SSL auch problemlos aufgelöst wird. Allerdings scheint der Servername von der NGinX-Konfigurationsdatei nicht erfasst und dann nicht korrekt an NextCloud übergeben zu werden, aber ich weiß nicht, was ich genau ändern soll.

Da ich glaube, dass ich es auf das eingegrenzt habe, was meiner Meinung nach das spezifische Problem ist, kann mir vielleicht jemand bei der Überprüfung der NGinX-Konfigurationsdatei nextcloud.conf helfen und darauf hinweisen, was falsch eingestellt ist.

Danke, dass Sie diesen langen Beitrag überhaupt gelesen haben.

Answer 1

Ich habe es herausgefunden und werde daher detaillierte Informationen bereitstellen, um Leuten zu helfen, die bereits das gleiche Problem haben, und Leuten, die in Zukunft möglicherweise darauf stoßen, wenn man bedenkt, wie viele Fragen und Probleme ich hierzu ohne Antworten gefunden habe.

Das Problem war der FPM-Stammspeicherort in den FastCGI-Parametern der NGinX-Conf-Datei

Ich war also auf dem richtigen Weg und das Problem hing mit der Root-Direktive zusammen.

Nach langem Lesen bin ich auf diesen Beitrag gestoßen:

Wie verknüpft man PHP-FPM- und Nginx-Docker-Container richtig?

Und plötzlich wurde klar, dass ich zwei verschiedene Dienste hatte, die zwei verschiedene Pfade lasen, und einer speiste den Stammpfad des anderen, wo dieser nicht existierte.

Erinnern Sie sich, dass ich das WWW-Volume zur gemeinsamen Nutzung durch die beiden Container gemountet habe?

1. Für den NGinX Container aufwww:/usr/share/nginx/html
2. Für den NextCloud FPM Container aufwww:/var/html/www

Die Idee dahinter war, dass die beiden Container das Dateisystem der NextCloud-App gemeinsam nutzen.

Was mir nicht klar war, ist, dass der Zweck von NGinX in dieser Bereitstellung darin besteht, die statischen Dateien wie CSS, HTML, JPG, JS usw. bereitzustellen und gleichzeitig PHP-Aufrufe mit den FastCGI-Parametern an den NextCloud FPM-Container weiterzuleiten.

Wenn die Root-Direktive in der NGinX-Konfigurationsdatei deklariert wird, wird sie als Variable festgelegt $document_root.

root /usr/share/nginx/html;

Wenn also die Wurzel auf den Pfad im NGinX-Container gesetzt wird, /usr/share/nginx/htmlfunktioniert dies, um die statischen Dateien ohne Probleme bereitzustellen. Wenn dann jedoch ein PHP-Aufruf erfolgt, wird dieser an den PHP-Handler im NextCloud FPM-Container weitergeleitet. Da dieser Speicherort im zweiten Container nicht existiert, kann er die PHP-Datei nicht finden.

Um dies zu beheben, habe ich nach dem Block mit den FastCGI-Parametern und der $document_rootVariable gesucht, sie gefunden und sie sieht folgendermaßen aus:

location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

Beachten Sie, dass die Zeile fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;„Skriptpfad“ mit bereits deklariertem Stamm erstellt, sodass bei der Verarbeitung nextcloud.example.comversucht wird, diesen zu lesen. index.phpDies ist der resultierende Aufruf des NextCloud FPM-Containers:

/usr/share/nginx/html/index.php

Der richtige Aufruf wäre gewesen:

/var/www/html/index.php

Also habe ich eine neue Variable mit dem Namen erstellt $fpm_rootund sie auf gesetzt /var/www/html/. Anschließend habe ich die Zeile geändert, in der steht fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;:fastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

Wenn es jetzt einen Aufruf für statische Inhalte erhält, wird der Containerpfad von NGinX aufgelöst und wenn es einen Aufruf für PHP-Inhalte erhält, der Containerpfad des NextCloud FPM.

So sieht der gesamte Abschnitt jetzt aus:

location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;
            set $fpm_root /var/www/html/;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

Es funktioniert jetzt und besteht alle internen Integritäts- und Sicherheitsprüfungen von NextCloud, nachdem ich die folgende Zeile hinzugefügt habe:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Abschluss

Und ich hoffe, dies hilft jedem, der nach diesem Problem sucht. Das Problem bestand darin, dass ich zwei verschiedene Pfade für die Dienste hatte, die beide Arten von Inhalten verarbeiteten, statisch und PHP, und nur einer davon war in der NGinX-Konfigurationsdatei richtig eingestellt.

Sie können zwei verschiedene (oder mehr) Stammspeicherorte für eine dockerisierte FPM-Bereitstellung haben, und dies könnte wahrscheinlich dazu ausreichen, mit statischen Inhalten in zwei oder mehr verschiedenen Apps zu arbeiten oder diese bereitzustellen, indem Sie denselben FPM-Container verwenden, um PHP-Aufrufe für NextCloud, WordPress, PHPPGAdmin, Laravel oder was auch immer Sie gerade bearbeiten, zu verarbeiten.