Cannot grant access

đŸ“± Desktop & mobile clients đŸ’» Desktop
26

Hi all,
I’m running Nextcloud in a FreeNAS jail and am having trouble getting my clients to access the server via my public facing domain. Through a web browser off of my network I can access my server just fine so I know it’s up and running. It is behind an Nginx reverse-proxy.
Editing config.php file in /usr/local/www/nextcloud/config to add ‘overwriteprotocol’ => ‘https’ does not work for me for allowing the android client to access my nextcloud server off of my LAN.

Does anyone have a solution for this? It doesn’t seem like it should be a complicated issue especially in this case where I know the server is accessible publicly in the first place.

27

I also had this problem, on only one of my machines not the other one (but both run Debian 10 and version 2.5.x from the PPA).

Nextcloud server is installed without a proxy and ‘overwritehost’ => ‘https’ did not fix the issue as that only fixes it when it’s behind a proxy (like with Docker deployments).

it definitely seems like a bug in the version 2.5 Nextcloud desktop for Debian 10 Buster, possibly more systems. The symptoms are the same: it loops around between the login screen and the grant access screen, never getting logged back in. It used to work until one day it broke. It doesn’t break every time (my desktop and laptop both run same versions of linux and are hooked up to same 4 nextcloud servers, it only broke on one machine on one server).

To make my account sync again, I built myself version 2.6 from the Git 2.6-stable branch, and that worked well but it took me some time to get it to work. I had a linker/library version conflict with the old libnextcloudsync that was installed from the packages. once I removed libnextcloudsync* and nextcloud* , I then had a missing libnextcloudsync.so error. I had to add my /home/me/nextcloud-desktop-client/lib/x86_64-linux-gnu/ to /etc/ld.so.conf and then “ldconfig -v | grep libnextcloudsync” to confirm it was seen by the system.

Finally after all that, i was able to run bin/nextcloud and immediately I was able to reconnect the one failed account in the settings. It didn’t prompt me for password at all (I was already logged in) and let me press Grant access and then everything started syncing again.

So that worked but probably won’t be easy for any non-developers. For anyone else using Debian and having this login/grant access loop issue, your best bet is to probably just download the pre-built version 2.6, 2.7, or 3.x version of Nextcloud Desktop. Then make the downloaded .AppImage file executable and you should be able to then just run it (make sure the old one is quit first) and it will hopefully get you logged back in and working. If so uninstall the old one and use the newly downloaded AppImage one until the PPA’s get upgraded to 2.6/2.7.

As the bug is already fixed in the code, this isn’t really something to take up in Github, it will get fixed when the PPA’s for Debian ship version 2.6+

28

I had the same problem with docker nextcloud 20.0.1. As discussion above I added **‘overwriteprotocol’ => ‘https’, ** in config.php then it’s ok!
Thank you, everybody!

29

Fixed my issue as well!

30

Hi all, I’m also running Nextcloud from behind an NGNIX reverse proxy with letsencrypt and I encountered (and solved) the same problem on both android app and Windows Client
The error in the browser console was the following:
[nextcloud nginx Refused to send form data to ‘http://mydomain.com/login/v2/grant’ because it violates the following Content Security Policy directive: “form-action ‘self’”.]

additionally to add
‘overwriteprotocol’ => ‘https’
I also modified the line:
‘overwrite.cli.url’ => ‘http://mydomain.com’
to
‘overwrite.cli.url’ => ‘https://mydomain.com:443’

that fixed the issue
Related to find the config file in docker it is on the nextcloud app container volume (if you used one) I would suggest to create volumes as indicated in the examples at github nextcloud/docker

31

For me this still does not work.

I use NextCloud 20.0.4, I use Docker compose and the Traefik proxy. I have added

`overwriteprotocol` => `https`

Allthough nobody specifies where, I tried several positions, currenty it is here (at the very start of the file):

?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  `overwriteprotocol` => `https`,
  'apps_paths' =>
  array (

I also changed

'overwrite.cli.url' => 'https://cloud.mydomain.nl',

I set Traefik to reroute http to https (this works). I tested client 2.6 from the Ubuntu 20.04 repo’s and also the AppImage (3.1.1). Nothing worked. Any other suggestions? Is there perhaps a way to set up the sync client with an app-password? I do have TOTP 2fa enabled.

I just tested the config based http>https and the Traefik one, they both work separately from each other, still, the access granting does not work.

Thanx,

Freek

Edit: I fixed this by temporarily setting
security.csp.enable
to False in the about:config of Firefox.

32

Thank you so much, your answers helped me solve this problem instantly!

This is what I did:

got container name (last column):
docker ps | grep nextcloud

bashed inside:
docker exec -it CONTAINER_NAME bash

Had to install vim:
apt-get update
apt-get install vim

vied into the config.php file:
vi ./var/www/html/config/config.php

added 'overwriteprotocol' => 'https', to the line before the last line, so it looked like this:

image

Amazing, thanks!

1 Like
33

worked for me, thanks!

34

Hello,

i would like to investigate here in this topic because i have the same problem.

First i want to sum up what i think is the status:

The problem depends on the docker-installation of nextcloud.
If you use “only” docker it helps to use the overwriteprotocol-option.

But those of us using a reverse-proxy between internet and nextcloud it doesn’t help.

So from my point of view, we need further actions on this topic.
Inbetween this time it helps to login via browser, generate an application-password and use this for login with the client.

But it would be nice to fix this also with reverse proxys.

Thanks

Btw
 from github-side this issue is closed: Login stalls at “grant access” with new login method on Docker installation · Issue #4786 · nextcloud/android (github.com)

35

Hi everybody,
I had pretty much the same problem (NC 20.0.7 running the official docker image with apache, plus reverse ssl proxy (nginx)). Even though overwriteprotocol was already set to https, I couldn’t grant access to new NC clients. In the firefox console I saw an error with the content security policy, but I didn’t want to override this. What did the trick for me in the end was to remove the overwriteconaddr parameter from the config.php!
Hope this helps anybody else!

2 Likes
36

After much back and forth (like 2 hours worth) - i finally stumbled upon the answer that works for me.

Background: Ubuntu 20.04 server, NGINX reverse proxy, NextCloud fresh install 20.0.7.

I found the manual/config info —> server/config.sample.php at master · nextcloud/server · GitHub

And I added the following to my /usr/share/nginx/nextcloud/config/config.php file:
‘overwrite.cli.url’ => ‘https://cloud.abc123com’, # originally it was http
‘overwritehost’ => ‘cloud.abc123.com’, # entirely new line
‘overwriteprotocol’ => ‘https’, # entirely new line
‘overwritecondaddr’ => ‘^192\.168\.1\.23$’, # IP of the reverse proxy
'overwritewebroot ’ => ‘/’, # entirely new line

37

Had the same problem, but I’m not using Nginx. I use Apache. However, not sure if my fix would help you all. But whatever. Here’s what I did. I tried the overwrite protocol: https as what raghnarok did, but it still didn’t work. So I edited the ‘overwritehost’ instead, adding the port number :444 at the end. It works now.

38

This is the best solution
 It worked for me, running nextcloud on docker with docker-compose-letsencrypt-nginx-proxy-companion.

39

Thanks a million.

It solved my problem:
overwriteprotocol => https

:sunglasses:

40

I had this issue using the nextcloud/helm chart and added the following custom *.config.php in the values.yaml to solve the access:

nextcloud:
  host: "nextcloud.example.com"
  configs:
    https.config.php: |-
      <?php
      $CONFIG = array (
        'overwritehost' => 'nextcloud.example.com',
        'overwriteprotocol' => 'https'
      );
1 Like
41

Sorry folks, I have tried all of the above recommendations in many different forms and nothing has worked. The only way to log on to Nextcloud through iOS was the QR code on desktop, but Nextcloud Talk get stuck at Grant Access.

I have an Apache Proxy that redirects to my NAS where Nextcloud is sitting.

My config.php currently stands as:

array (
‘trusted_proxies’ => ‘my.public.ip’,
‘overwritehost’ => ‘the.webaddress.net’,
‘overwriteprotocol’ => ‘https’,
‘overwritewebroot’ => ‘http://192.168.xxx.xxx:xxxx’, #this is the internal ip:port where Nextcloud is sitting
‘overwrite.cli.url’ => ‘https://the.webaddress.net’,
),

42

Hi there, I am unable to solve this issue, this is so weird. On my laptop, I managed to solve the issue by adding 'overwriteprotocol' => 'https'. However, on my phone I had to use a QR code (app password) to authenticate.

Now, I want to sync my desktop computer. 'overwriteprotocol' => 'https' doesn’t help. So I had the idea to try using an app password (as I did for my phone) but I have a very weird bug. In the browser, I have an error message telling me that the username or the password is wrong BUT in the page where I created the app password I can see a successful authentication in the list of sessions (“Devices & sessions”). Because of that, I cannot use the same trick as on my phone and I am truly unable to grant access to my desktop computer.

I saw some people mentioning that having a reverse-proxy makes a difference and that the overwriteprotocol trick doesn’t work in this case. In my particular case, I use Traefik. Is there someone who had to deal with this issue while using Traefik? Can someone please help me? It’s driving me crazy :sweat_smile:

Or maybe, as several people are unable like me to solve this issue, should we open an issue on Github?

43

Hi again :wink: I found a hack to bypass the issue. It is not a fix but it allowed me to authenticate for this one time. I think it might be helpful for people who are unable to fix the issue with overwriteprotocol, so I will try to explain what I did there.

In the browser window (I use Firefox), instead of clicking on the “Grant Access” button, right click on the button and “Inspect”. In the HTML source, look for the URL of your server. Basically, the button is programmed to execute a POST request using this URL. The problem is that the URL starts with “http” instead of “https”. Now, right click on the code and “Edit As HTML”. Add a “s” manually so that the URL looks like “https://”.

Now, click on the “Grant Access” button. As you edited the URL, the POST request will use the right protocol and it should work :slightly_smiling_face:

If I understood well, overwriteprotocol is supposed to replace “http” with “https”. My hack consists in doing this job manually, basically :sweat_smile:

I hope it will be helpful :slightly_smiling_face:

44

Thanks, this did the trick for me as well!

45

Removed the Header and now iOS works! :+1: