Nextcloud version: 11.0.2
Operating system and version: Debian 9
Apache or nginx version: nginx v1.11.10
PHP version: 7.0
Is this the first time you’ve seen this error?: it’s a fresh installation, so yes
Can you reliably replicate it? (If so, please outline steps): yes
The issue you are facing:
My setup: Nextcloud in a chrooted PHP-FPM pool running behind of nginx. And Nextcloud in a subdir according to this config.
Now all requests to /nextcloud/apps/theming/img/core/filetypes/application-pdf.svg?…
and some other SVG files, which do not really exist and have to be redirected to PHP, always returned an 404 error.
The reason is these requests are requested from the root dir (internal path of /
) where they just do not exist.
By modifying the nginx config I found out that the request with the default config was redirected to this one:
/nextcloud/index.php/nextcloud/apps/theming/img/core/filetypes/application-pdf.svg
(notice the two nextcloud
subdirs there) in the location ~* \.(?:css|js|woff|svg|gif)$ {
block, which obviously let the request fail.
So for anyone experiencing this, a named location, which rewrites the URL by removing the first subdir fixes this issue:
In subdir:
location ~* \.(?:css|js|woff|svg|gif)$ {
add_header X-Download-Options noopen;
[…]
try_files $uri @nextcloudproxy;
#try_files $uri /nextcloud/index.php/$uri$is_args$args; # buggy because of subdir
access_log off;
}
Anywhere:
location @nextcloudproxy {
rewrite /nextcloud/(.*) /nextcloud/index.php/$1;
}
The output of your Apache/nginx/system log in /var/log/____
:
2017/03/12 […] [error] 30111#30111: *74 open() "/WONGRDIR/index.php/nextcloud/apps/theming/img/core/filetypes/application-pdf.svg" failed (2: No such file or directory), client: […], server: […], request: "GET /nextcloud/apps/theming/img/core/filetypes/application-pdf.svg? HTTP/2.0", host: "[…]"
I’ve got a similar issue with the getstoragestats.php
or enableapp.php
files (it seems to affect all AJAX php files), which also always returns 404, but here no errors are logged into nginx. Maybe I’ll open another thread for this if I don’t figure out how to fix this thing.
Of course it would be glad if these things could be fixed directly in Nextcloud, so that these workarounds in the nginx config are not necessaries.