help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.
In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:
example
Or for longer, use three backticks above and below the code snippet:
longer
example
here
Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can
Nextcloud version (eg, 12.0.2): 18.0.3
Operating system and version (eg, Ubuntu 17.04): ubuntu-server 18.04.4
Apache or nginx version (eg, Apache 2.4.25): NGinx 1.17.4
PHP version (eg, 7.1): 7.3
Is this the first time you’ve seen this error? (Y/N): N
Steps to replicate it:
repair the RequestOptions::TIMEOUT => 30 , value in /var/www/nextcloud/lib …
set value to a working value RequestOptions::TIMEOUT => 600,
make the update to NC 18.0.3
see your error log and see that the error is back
repair the file “Client.php” again and remark that the error disappears again
I have adjusted that value already in 18.0.1 and again in 18.0.2 now a third time.
Please set the default value in this file “Client.php” to RequestOptions::TIMEOUT => 600,
Please make change request to the code in the bug tracker: https://github.com/nextcloud/server/issues
However, such long time to connect is a bit strange. Do you have a slow internet connection or do you have network problems?
It is recommented that since document server is integrated in Nextcloud, app store should have a larger Timeout value because your shop is too slow for that amount of data.
Or DNS problem, that getting the hostname the first time takes a long time? If you use the command line, they disabled the timeouts since 18.0.2, so if you use the occ command it should be working (https://github.com/nextcloud/server/pull/19430). For the webinterface, they are more careful not to end up with a non-responsive update procedure just because something is not available (servers down, non-working internet connection, …).
OK Nextcloud Updater should then be more attentive with existing Configurations!
It is senseless if NC ignore those settings without questioning to change existing settings.
NC should more carefully like samba or other serverside settings. When updating here with a new config then the (linux) updater is asking the admin for overwrite config or leaving existing one.
Or make the Timeout Value as variable that could be set by admin and can be read by the config file, so that values stay unchanged.
Or give the local admins more options to modify the update process so that you have the choice to leave files modified and not overwritten by a “stupid” updater.
And i’m not alone with the problem, that the existing Timeout Limits are too strong for many others either. When the same problem has been posted again and again (thanks for the links of the issue github db) then it might be a good advice to investigate why higher values solve the timeout problems and why other admins who recommend those values (see my link in post 3) running better with that.
Sorry, but this is no option or setting. You just manually changed the code. How do you want an updater app to know, if such a manual change will work in a new version? If they changed the logic of some function or even removed parts of the code that you changed?
That would be the proper solution. Make a feature request on github.
Sure that would be great. If it is not the connection speed like in your case, it would be great to know. However, it needs a system with that problem. From the logs, it seems that curl is used, if you get the URL that creates the large timeout, you can manually start curl from the command line in debugging mode (option -v, add more v to increase debug level) so you can see what takes so much time.
