same issue here. (docker container+swag (letsencrypt+nginx container) for rProxy)
What iâve noticed is all URLâs in the webui are pointing to HTTPS apart from the webdav and the Server address URL given at https://serverFQDN/nextcloud/settings/user/sync-clients which both reference http:// locations. Iâm assuming the desktop client is using the Server Address URL as given on that sync-clients page and thats the issue, but how do we fix?
lilâ help here please on what needs to be done!
edit: SOLVED for me. turns out i was missing âoverwriteprotocolâ => âhttpsâ, in config.php. Iâm guessing something has changed recently as my previous build notes havent covered this and nore does swags included rproxy nextcloud config.
Hello, I have the same problem and for me adding overwriteprotocol is not working, and overwritecondaddr is not set. My nextcloud is old, 14.0.11, hope that this does not matter, I am stuck on this version and canât upgrade.
By the way, Iâm okay with just forcing the URL if I can do that somewhere, itâs just a small install for myself and all I need is this login to succeed.
I have nextcloud installed on a ubuntu 20.04 server (nextcloud) behind a ubuntu 20.04 reverse proxy server. Both use apache2. They are in separate boxes and both use private IPâs (192.168.x.x). Clients receive a certificate from the proxy and are then proxied to nextcloud using proxypass and proxypassreverse. Hence, the client uses https but from then on the two servers use http.
I have set up webdav on nextcloud.
Nextcloud at its web interface works fine and I can map the webdav directory to the nextcloud installation using Windows 10.
I have installed the nextcloud app on Windows 10 but I cannot initialise it. It refuses to accept that I am using https.
Part of the problem is that I canât find documentation on the meaning of directives in the config. I am worried about âoverwriteâ because any rewrites should be handled by the proxy. Nextcloud is no use to me without the sync function which appears to be unavailable without the desktop app. I think the problem is the nextcloud config which may have been designed without attention to having a reverse proxy in a separate box. There may also be conflicts with the apache2 proxypass directive as I am not using the alternative rewrite protocol and the nextcloud config may assume I am. I donât want to install a private cert on nextcloud because I donât see any security problems with using http on the private LAN
my config is:
$CONFIG = array (
âtrusted_proxiesâ => [âIP of proxyâ],
âinstanceidâ => âxyzâ,
âpasswordsaltâ => âxyzâ,
âsecretâ => âxyzâ,
âtrusted_domainsâ =>
array (
0 => âproxy name in /etc/hosts:8080â,
),
âdatadirectoryâ => â/var/www/html/nextcloud/dataâ,
âdbtypeâ => âmysqlâ,
âversionâ => â22.1.1.2â,
âoverwrite.cli.urlâ => âhttp://nextcloud name in /etc/hosts:8080â,
âdbnameâ => âxyzâ,
âdbhostâ => âlocalhostâ,
âdbportâ => ââ,
âdbtableprefixâ => âoc_â,
âmysql.utf8mb4â => true,
âdbuserâ => âxyzâ,
âdbpasswordâ => ââ,xyz
âinstalledâ => true,
âapp_install_overwriteâ =>
array (
0 => âtwofactor_yubikeyâ, # I donât know why this is here as another problem is that I canât setup a yubikey - what does the â0â mean?
),
);
I have now found the config file documentation. I have added overwriteprotocol setting it to http. So I assume that will force http back to the reverse proxy. I have also added the proxy to trusted domains in all its different forms. Neither of these things have made any difference. I still get the error that polling http! I still canât log in to the desktop app.
Finally, this solved my issue! Thank you so much!
My wife and me were stuck with Client version Nextcloud-3.2.4 and now it is working again.
But i am still concerned that this can not be the most healthy way to do this. Some day this might backfire when every switch i had to flip to make things work start to collide with each other.
Had the same problem like here described, tried every configuration and nothing helped⌠except a restart of the docker container with the following configuration
So, since I posted this I have now managed to resolve the issue. There were two things I had to do above having the overwriteprotocol and overwrite.cli.url set. I had to remove overwritecondaddr which wasnât enough on itâs own but a necessary step. My regular setup has a redirect from http to https to enforce the use of https, I had to remove this for the duration of the client installs. Once I was logged in and working then I could re-enable this step. Iâm aware that I may have to disable this every time I have to install a new client but at least Iâm up and running for now
