Hello! I've been staring at this for quite some time at this point and could really use a hint.
I'm attempting to run the nextcloud:fpm image and expose it via nginx running on the host. When I load https://cloud.example.com in my browser, all I see is the infamous "File not found." message. Permissions don't seem to be an issue as I can shell into the container and the perms on /var/www/html/index.php look fine:
-rw-r--r-- 1 www-data root 3664 Jul 23 18:11 index.php
What might I be missing?? I would really appreciate any ideas.
$ docker run -d -v /opt/nextcloud_data:/var/www/html -p 9050:9000 nextcloud:fpm
14b742b7850f89878b0370a06dd78dea92bfc64630cb132a453e9e5db2679f93
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14b742b7850f nextcloud:fpm "/entrypoint.sh php-…" 7 seconds ago Up 6 seconds 0.0.0.0:9050->9000/tcp pensive_nobel
$ docker logs 14b
[23-Jul-2018 18:39:39] NOTICE: fpm is running, pid 1
[23-Jul-2018 18:39:39] NOTICE: ready to handle connections
172.17.0.1 - 23/Jul/2018:18:40:18 +0000 "GET /index.php" 404
172.17.0.1 - 23/Jul/2018:18:40:18 +0000 "GET /index.php" 404
How is /index.php a 404? The file is right there... I know it's not executing the php because adding a die("test"); right after the <?php doesn't seem to get hit -- same "File not found." result.
Nginx log (running on the host):
192.168.0.1 - - [23/Jul/2018:14:43:05 -0400] "GET / HTTP/2.0" 404 36 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36 OPR/54.0.2952.51"
Nginx vhost:
upstream php-handler {
server 127.0.0.1:9050;
}
server {
listen 80;
listen [::]:80;
server_name cloud.example.com;
# enforce https
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name cloud.example.com;
# ssl_certificate /etc/ssl/nginx/cloud.example.com.crt;
# ssl_certificate_key /etc/ssl/nginx/cloud.example.com.key;
ssl_certificate /etc/letsencrypt/live/cloud.example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/cloud.example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this
# topic first.
# add_header Strict-Transport-Security "max-age=15768000;
# includeSubDomains; preload;";
#
# 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 X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
# Path to the root of your installation
root /opt/nextcloud_data;
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
# last;
location = /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}
# 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/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;
location / {
rewrite ^ /index.php$request_uri;
}
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_pass php-handler;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
#Avoid sending the security headers twice
fastcgi_param modHeadersAvailable true;
fastcgi_param front_controller_active true;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}
location ~ ^/(?:updater|ocs-provider)(?:$|/) {
try_files $uri/ =404;
index index.php;
}
# Adding the cache control header for js and css files
# Make sure it is BELOW the PHP block
location ~ \.(?:css|js|woff|svg|gif)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463";
# Add headers to serve security related headers (It is intended to
# have those duplicated to the ones above)
# Before enabling Strict-Transport-Security headers please read into
# this topic first.
# add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
#
# 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 X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
# Optional: Don't log access to assets
access_log off;
}
location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
try_files $uri /index.php$request_uri;
# Optional: Don't log access to other assets
access_log off;
}
}
I tried running the container with --user 33:33 (that's my arch linux http user/group ids). I tried chmod -R 755 /opt/nextcloud_data ...
From its logs, php-fpm seems to get the request... but why does it return 404?
Wow! That was a snag. Thanks to this StackOverflow page, I was able to discover that the nginx "root" prefix is sent along to php-fpm, so that path prefix needs to inform the container where the files are. Of course the location is different between the container and my host.
I found that if I just changed the root (directly under server {}), all urls simply respond with unstyled html of the root page since nginx found no static files at the configured root. But when I reverted root to reflect the host and added a new root inside the php-fpm block, I won!
Sorry for the noise, but who knows - maybe this will help someone.
# ...
location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
#Avoid sending the security headers twice
fastcgi_param modHeadersAvailable true;
fastcgi_param front_controller_active true;
# fastcgi_pass 127.0.0.1:9050;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
root /var/www/html/;
}
# ...
Absolutely same as my scenario, which nginx is out of docker, only php-fpm and postgres in docker-compose.
When I add root /var/www/html to that block, finally could access.
Wow! That was a snag. Thanks to this StackOverflow page, I was able to discover that the nginx "root" prefix is sent along to php-fpm, so that path prefix needs to inform the container where the files are. Of course the location is different between the container and my host.
I found that if I just changed the
root(directly underserver {}), all urls simply respond with unstyled html of the root page since nginx found no static files at the configured root. But when I reverted root to reflect the host and added a newrootinside the php-fpm block, I won!Sorry for the noise, but who knows - maybe this will help someone.
# ... location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) { fastcgi_split_path_info ^(.+?\.php)(/.*)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param HTTPS on; #Avoid sending the security headers twice fastcgi_param modHeadersAvailable true; fastcgi_param front_controller_active true; # fastcgi_pass 127.0.0.1:9050; fastcgi_pass php-handler; fastcgi_intercept_errors on; fastcgi_request_buffering off; root /var/www/html/; } # ...
I tried this method, but still failed. But this answer gave me some hint. I modify as follow
fastcgi_param SCRIPT_FILENAME /var/www/html/$fastcgi_script_name;
# root /var/www/html/;
fastcgi_index index.php
Hope this can help someone.
Most helpful comment
Wow! That was a snag. Thanks to this StackOverflow page, I was able to discover that the nginx "root" prefix is sent along to php-fpm, so that path prefix needs to inform the container where the files are. Of course the location is different between the container and my host.
I found that if I just changed the
root(directly underserver {}), all urls simply respond with unstyled html of the root page since nginx found no static files at the configured root. But when I reverted root to reflect the host and added a newrootinside the php-fpm block, I won!Sorry for the noise, but who knows - maybe this will help someone.
https://stackoverflow.com/questions/29905953/how-to-correctly-link-php-fpm-and-nginx-docker-containers