Desktop: Login on MacOS Client v2.6.1 doesn't work

[milefork]

As the title states, there is an issue with the actual MacOS Client v2.6.1 macOS 10.12+

When you install it and open it to enter the nextcloud server url it tries to resolve something and then says /status.php is not found.
Accessing /status.php on my server works and downgrading the Client to v2.6.0 also works in the initial setup!
My server is accessible via https and on the internet.
So in conclusion there must be a bug in the v2.6.1 client.

[tflidd]

Can you check in your webserver logfiles (access.log and error.log) if you can see what the MacOS-Client is trying to access (perhaps just with http).
Check also if you have installed a fancy firewall solution, if that blocks a newly installed software from connecting to the internet.

[milefork]

No, sadly I can't find any log files on that any more.
But I've no enabled firewall on that Macbook.
Also right after uninstalling 2.6.1 and installing 2.6.0 it worked.
In 2.6.1 I tried both https and http urls and they doesn't work.

[milefork]

So I upgraded my client now to 2.6.1. Now the client says no connection to .... timeout.

I'm running my server with an apache reverse proxy it seems that the client tries to reach this url:

[25/Nov/2019:18:11:20 +0100] "GET /ocs/v2.php/core/navigation/apps?absolute=true&format=json HTTP/1.1" 304 4064 "-" "Mozilla/5.0 (Macintosh) mirall/2.6.1stable (build 20191105) (Nextcloud)"

Which results in a 304. When I call it via the browser I get a normal response with 200.

I know 304 is not modified, maybe the client expects 200?

My running apache config looks like this:
https://pastebin.com/xiitRHRC

And it is connecting to the nextcloud docker container.

[chmanie]

I can confirm this, having the exact same issue. 2.6.0 is the last client that works for me. I tested with nextcloud server installations 15.x up until 17.x (I upgraded) with no luck. Let me know if I can help by providing logfiles.

Plus, it's not only the first time login. If you set up nextcloud with a working client, then install 2.6.1 it won't connect anymore (timeout).

[milefork]

@chmanie

Plus, it's not only the first time login. If you set up nextcloud with a working client, then install 2.6.1 it won't connect anymore (timeout).

yes, that was what I'was trying to say in the post above you.

I'll try to change the bug title.

[kermit-frog]

Same issue here.

I had a working 2.6.1 client on Sierra which I tried to update to v2.6.2.

After update no sync anymore so I removed the account from the client and tried to register it again.

After entering the https-URL the client tries to resolve something and ends up with status.php not found.
Downgrading to 2.6.1 again or upgrading the client to 2.6.3 / 2.7.0 didn't do anything.

Firewall off.
🤔

[chmanie]

I've checked my access logs and the connection attempt doesn't even appear in there. This problem seems to persist in all versions above 2.6.0 (including 2.6.3) and also with all Nextcloud versions that I tried (15-18). I'm willing to help to debug this but I have no idea on how to start. It'd be great if someone could help us out here.

[kermit-frog]

This solution here worked for me: https://github.com/nextcloud/desktop/issues/1728#issuecomment-583757990

'overwrite.cli.url' => '[httpS://your-domain]',
Use this configuration parameter to specify the base URL for any URLs which are generated within Nextcloud using any kind of command line tools (cron or occ). The value should contain the full base URL: https://www.example.com/nextcloud

'overwriteprotocol' => 'https',
When generating URLs, Nextcloud attempts to detect whether the server is accessed via https or http. However, if Nextcloud is behind a proxy and the proxy handles the https calls, Nextcloud would not know that ssl is in use, which would result in incorrect URLs being generated. Valid values are http and https.

I have contacted my provider and asked him to look at the solution from this thread. From there the settings (overwriteprotocol und overwritehost) were set and after that the registration could be done without any problems.

@g-work

[chmanie]

'overwrite.cli.url' => '[httpS://your-domain]',

I am confused by this. Should this be in brackets? Is the S needed? My config reads:

'overwrite.cli.url' => 'http://my.domain.com', // replace with actual domain, no https, just http
'overwriteprotocol' => 'https'

[kermit-frog]

I am confused by this. Should this be in brackets? Is the S needed?
```

I am sorry, but I don't know more than that. My provider just told me to have changed these settings.

[N4IR0]

'overwrite.cli.url' => '[httpS://your-domain]',

I am confused by this. Should this be in brackets? Is the S needed? My config reads:

'overwrite.cli.url' => 'http://my.domain.com', // replace with actual domain, no https, just http
'overwriteprotocol' => 'https'

In our case it was enough to set the following settings (overwritehost without the protocol):

'overwriteprotocol' => 'https',
'overwritehost' => 'your-domain.com',

Additionally we set the cli url by default:

'overwrite.cli.url' => 'https://your-domain.com',

[milefork]

@kermit-frog @N4IR0 are you also talking about the macOS client? I've all the settings since I created this bug. My Windows clients are working perfect on the current version.

May mac client only works on 2.6.0. So I think this is a mac specific issue.

[kermit-frog]

@kermit-frog @N4IR0 are you also talking about the macOS client? I've all the settings since I created this bug. My Windows clients are working perfect on the current version.

May mac client only works on 2.6.0. So I think this is a mac specific issue.

That is correct. The solution worked for my Mac client (Sierra). I am on 2.6.3 now.

[chmanie]

So I have the problem now that it just works intermittently.

This is the error I'm getting now.

While the server seems to work fine and is reachable via the browser. And sometimes it just works without any issues whatsoever. So this is really confusing me.