Repository navigation
Regression: Removed upload and memory limit settings resulting in lower effective defaults since Nextcloud 16 #18655
Description
Hi,
pull request #14430 removed the upload and memory settings from Nextcloud after discussion in issue #13990.
While I fully understand the reasoning behind it, the discussion was missing a point and, hence, I think the solution taken is not the best approach but constitutes a regression.
The solution was based on the assumption that it's best to change the upload and memory limits in the global server/php configuration. And if you wouldn't have access to the global configuration (in a shared host environment), you wouldn't have much reason to decrease the limits in the local configuration.
And that's the issue: It is possible to have low limits in the global configuration and increase them in the local configuration! I run Nextcloud in a shared host environment. The hoster has low memory and upload size limits by default (128M and 200M). But the hoster allows to increase the limits manually via .htaccess/.user.ini. So, up until Nextcloud 15, the memory limit was automatically increased to 512M via .htaccess and I set a custom upload size limit in the admin settings.
With Nextcloud 16, these settings are gone. So, Nextcloud now runs with the low default limits which in turn results in a warning message in the admin panel as the memory limit is lower than 512M.
If I manually add them to .htaccess, they get removed with the next update (see issue #6248). This makes it hard to manually configure the memory and upload limits in a shared environment.
IMHO a better solution to issue #13990 would be to make these settings configurable, but leave them unset/empty by default. There wouldn't even need to be a GUI setting for all of this. An optional setting in config.php would be simple enough, I guess.
Steps to reproduce:
- Run Nextcloud 15 in an environment with low default global memory and upload limits, e.g. 128M and 200M, that may be increased locally.
- Increase the upload limit in the admin panel.
- Check the effective settings in the monitoring tab. It should show a memory limit of 512M and the upload limit as set in step 2.
- Install Nextcloud 16 in the same environment.
- Check the effective settings in the monitoring tab. It will show a memory limit of 128M and 200M upload limit. In addition, the overview tab will show a warning about the low memory limit.
My personal workaround for now is a script that adds these settings to .htaccess and if they get removed due to an update, add them again. But that shouldn't be necessary and leads to a new issue (the integrity check complaining about an extra file in the installation).
Cheers,
Timo
Activity
kesselb commentedon Jan 5, 2020
We have plenty of these discussions: Should nextcloud try to configure the environment or just work with any environment.
Examples:
In general: Adding another flag will add more complexity. A and B needs to be tested then. So probably the CI should run both variations.
This: Something like if memory_limit < x try setting a higher value is possible. Probably not with a custom value (because this limit must be set early). upload_max_size is not required anyway because the (official) clients upload big files in chunks.
Never the less: I'm against it ;) Setting other values for memory_limit or upload_max_size is a webhosting standard feature nowdays. For example it's possible with Plesk for a long time. If your webhosting provider do not offer a way to set higher values it's probably time to change.
I cannot recommend any hosting provider. 1and1 (according to a german magazine) forbid software like Nextcloud and for one.com there are some reports that
set_time_limitis blocked which is also required for Nextcloud.It guess it's possible to append new lines to .htaccess without triggering the integrity check. So if you put this "patch-htaccess-after-update" file outside nextcloud's directory this is fine.
server/lib/private/Setup.php
Lines 501 to 502 in bdf48d8
If you want to contribute. Above method will run during each upgrade or via
php occ maintenance:update:htaccess. The line will read a value from configuration and will append something if not empty. You could add something likehtaccess.OverwriteMemoryLimitand if set append thesephp_admin_flagvalues to $content.silentcreek commentedon Jan 6, 2020
I think what you actually mean is: Should nextcloud try to configure the environment or attempt to run with what is given and leave the configuration up to the user/admin ;)
Working in any environment would be to leave users as much freedom as possible which could include lots of configuration options.
I understand. But to me the issue at hand boils down to two things:
It worked before, now it doesn't anymore (at least with limitations). I'd consider that a bug and not a new feature, unless nextcloud was never intended to run in such an environment and worked just by coincidence before. Yet, I guess there was a reason the memory limit was defined by nextcloud in the past.
The more I think about it, the less I'm sure that my suggested solution is actually the best way to go. I think the more serious issue is that nextcloud is taking full ownership of the .htaccess and .user.ini files which would give users the opportunity to adjust their server configuration as they see fit.
Wouldn't it be "early enough" if it's included in .htaccess? So, if I were to take the route you suggest and patch Setup.php, we could have a configuration option that would be written to the .htaccess file after each upgrade. Or do you mean it should already be set during the installation itself?
I guess that doesn't apply to the web interface, right? Because that's what I mostly use.
Well, the point is, my host does allow me to customize these settings via .htaccess. Why would they have any inclination to offer me more than one way to do so, just because an app wants to use the file exclusively. In any case, changing my hoster is not an option for me at this point. I'm quite happy with them for a long time and I wouldn't change that just because of this issue.
I've done that today. Had to change my setup a bit to allow for that, but it works now.
I'm not a PHP developer, but it seems simple enough that I might give it a shot. But coming back to my second statement above - that I don't think nextcloud should assume exclusive ownership of .htaccess or .user.ini - I had another idea today. So, how about this:
Instead of implementing multiple new configuration setting that would be added to htaccess, how about the ability to allow the user to have something like an .htaccess.inc file that will be appended to the .htaccess file with every update if it is present (or a configuration option that allows the user to specifiy a file that he wishes to append). That would give users the ability to define their own settings if they need, but wouldn't add more configuration options (the same goes for .user.ini). I've seen some bug reports here, where people complain that their settings get overwritten during an update, so I guess there's some demand for that. And with such an include file, users could also create them prior to the installation process so the installer could actually use them, too (if the filename and location were to be fixed).
Does that sound like a sensible solution? Or would you prefer additional configuration options?
kesselb commentedon Jan 6, 2020
Web interface is also using chunks.
Yes.
.htaccessis early enough.No and No ;)
Such a mechanism is a common way to solve such problems yes. For example It's possible to overwrite the mimetype definitions for nextcloud like this. I don't see the need for more complexity here. The best way to solve this is to remove the ownership of
.user.ini. We should still ship it but exclude from integrity check and don't overwrite on update..user.inilooks like the best way to configure a environment. We should review all theini_setcalls in https://github.com/nextcloud/server/blob/master/lib/base.php and also put some of them into.user.ini. I think that would improve the situation in general. More configuration options or merge custom changes logic will not.szaimen commentedon May 28, 2021
Is this Issue still valid? If not, please close this issue. Thanks! :)
silentcreek commentedon Jun 1, 2021
The issue that .htaccess gets overwritten with every upgrade is still valid, yes. I currently have a workaround in place in form of a script executed via cron that will add my custom additions to the .htaccess file again after every upgrade.
I will check whether kesselb's latest changes to the .user.ini handling make any difference. But last time I checked, .user.ini wasn't helpful in my environment...
silentcreek commentedon Jun 16, 2021
So, I looked at this again, and yes, the issue is still relevant. At least until issue #19935 is not resolved, .user.ini isn't helpful since `occ integrity:check-core' will complain if I add custom settings to the .user.ini file. So, I'll have to leave them in .htaccess for now and readd them after each update.
kesselb commentedon Jun 17, 2021
As this sounds like a nice feature, the requests for this are quite low. Currently there are no plans to implement such a feature. Thus I will close this ticket for now.
szaimen commentedon Jun 17, 2021
Please follow #19935 as this is a more reasonable feature request.