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:
Or for longer, use three backticks above and below the code snippet:
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
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?
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.