Nginx with subdir and chrooted php-fpm returns 404 errors for some (SVG) files

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;

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.

I had the same problem, albeit with a different setup:
NC version: 12
OS: FreeBSD 10.3 (FreeNAS 9.10)
nginx 1.10.3
PHP 5.6 (php-fpm)

For me the issue was resolved by removing fastcgi_param front_controller_active true; from the php location block. I don’t know the purpose of setting this parameter, but haven’t noticed any issues since removing it.

Same issue here. Disabling front controller works, but pretty URLs (without /index.php/) are gone. This is btw. the purpose of this directive.

For Apache, enabling pretty URLs also leaded to missing icons. This was solved by
Maybe for Nginx this has to be solved separately as well?

The fix was in the Nextcloud code, so it shouldn’t be web server specific. There were a couple of more fixes but I don’t know if all of them have been backported to NC 12 (surely not in the current release). You could try NC 13 beta: 85% faster LDAP, 10x read/write speed of Windows Network Drive: Welcome to Nextcloud 13 Beta
Open a new report on github if that doesn’t work either. Make sure that you use a current config from the repo:

1 Like

With 12.0.4RC1 the problem is not yet gone, will further test with NC13.

My config is based on the current docs :wink:, which include fastcgi_param front_controller_active true;
On ownCloud docs this is by the way also included, but commented out with little explanation, that it is in experimental state:

€: Ah, as for Apache at least the 'htaccess.RewriteBase' => '/', setting is necessary, is this for nginx also the case (does not solve the missing icons issue here), or is it just used by the occ maintenance:update:htaccess command to correctly enable pretty URLs for Apache in .htaccess?

€€: And bing NC13 Beta1 solves it :slight_smile:, @tflidd maybe you can mark this topic as solved. Thanks for the great work. I also like the new combined settings page, but yeah this belongs to another place.