Problem with file sharing app starting with 18.0.1 upgrade

ℹ️ Support
1

After upgrade from 18.0.0 to 18.0.1 a “bad gateway” error starts to occur. By trial and error I have determined the problem can be eliminated by disabling the file sharing app.

Nextcloud version 18.0.1:
Operating system and version Debian 4.19.37-5:
Apache or nginx version nginx_:
PHP version 7.3_:

When I did a automated system upgrade from 17.0.6 to 18.0.4 on my production system, I ran into the “bad gateway” problem. I then tested out the upgrade on a test system with little user data and had no problems. The production system has a few thousand shared files.

I then restored to 17.0.6 and manually upgraded to 18.0.0 without the problem. After a manual
upgrade to 18.0.1 the problem reappeared. Somewhere in my research I saw the problem could be caused by an app and so I started to disable apps until the problem went away. The problem definitely comes and goes with the file sharing app.

The “bad gateway” is due to a a large header as indicated in the nginx error log snippet below:

2020/05/30 20:32:55 [error] 28537#28537: *234 **upstream sent too big header** while reading response header from upstream, client:, server: , request: "GET /apps/files/ HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.3-fpm.sock:", host: ""
2

Do you have shell-access? Do you use web updater or shell-command?

https://docs.nextcloud.com/server/latest/admin_manual/maintenance/update.html

3

I have both. On the initial routine upgrade I used the web updater but then to recover and upgrade in small steps I used shell commands.

There is a similar post for a problem like this that says it was resolved by disabling and or removing a metadata app but I can’t find such an app on my system, not in the apps directory and then neither in occ disable or the admin web app tool. I checked my test system and could not find the metadata app there either.

4

Looks like this is related to your fastcgi_buffers of the server, check if this

helps you (setting

fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;

or similar.

/Simon

5

Thank you Simon for the advice. It looks to have solved the problem for me. I have no idea of the size or numbers of the buffers required, so I just used the numbers suggested.

I wonder if something like this should be put into the nginx config in the manual.

6

That’s a good question - I’m using the same stack as you but have never seen these errors and have not set the above variables (meaning they are probably at their defaults)