[Bug]: Version 3.9.1 cannot connect to server (but version 3.9.0 can) #5929
Comments
|
Here is the log (I have edited it to remove potentially identifying information): |
|
Same issue reproduced when using the flatpak version (Nextcloud desktop version 3.9.1). |
|
We have the same error ("Server is currently being redirected, or your connection is behind a captive portal."): Server: Nextcloud 25.0.7 on Ubuntu
3.9.0 worked flawlessly |
|
Same issue here on CentOS9 stream, had to revert to 3.9.0. |
|
Just wriging here to confirm that happends both in windows and macos, using latest stable owncloud server. Had to rollback to 3.9.0 |
|
I guess its related to this merge: e4816de Any hints where to check our configuration to not trigger this? |
|
Got the issue on Windows 10, after installation of version 3.9.0 everything is working again. Our server uses a shiboleth login, could this trigger the redirect warning? |
|
This was caused by the """feature""" in #5894 |
|
Question is whether this ancient ownCloud server SHOULD or SHOULD NOT be supported by the sync client. |
One thing has nothing to do with the other. As noted in a previous comment, the issue may be reproduced even against "Nextcloud server 25.x", which is not too old and indeed still supported. |
|
Sorry, should have read all comments more carefully. |
|
Posing this question for the distro maintainers or other admins providing nextcloud-desktop to users: How are you all handling this? Skipping (or delaying) 3.9.1 for now or just reverting commit e4816de with a patch? Thanks in advance for any helpful suggestions. |
|
It seems to me this was not fixed in 3.9.2, right? |
Nope, tested version 3.9.2 today morning and same issue shows up. |
|
It seems to me this wasn't fixed in 3.9.3 either (mainly a translation update) |
|
So does anyone know why this happens to some people but - well, not very many people, clearly - none of our customers has seen this, and they have a combined ~20 million users ;-) This must be a server configuration that is interacting with this captive portal detection. Does anybody know what exactly is happening, is there a redirect to their server? Might help debug it - the captive portal detection is a very helpful feature and I am not happy that my openSUSE client is now on 3.9.0 instead of 3.9.3. I'd really like those bugfixes and I bet so do many other users. My mac os system is on 3.9.3 and none of the 3 servers I connect to have any issues, so hum. Note on ownCloud: we don't support using such ancient, servers, sorry. There are so many potential issues with those, including many security related, and we do not test it at all. If you really want to use them - use an old client, or better - the ownCloud client. I'm honestly surprised it still works. As private user: just install the AIO and move data over. Much less maintenance work, better performance and security, and features of course. As a company or university - we happily help you migrate. I realize migration is of course still a pain - hey, I still use a Apache setup that breaks every now and then, but still haven't migrated to the AIO). But that's why I say - use the oC client if you still are on an old ownCloud setup. PS I'll ask @allexzander to see if he can fix this ;-) So please, provide info on if your server has some kind of redirect or is behind one, to help him debug - and hopefully he can find out the problem soon. |
|
I cannot help debug the server config since it isn't hosted by me. Nonetheless, I stress that introducing such a new feature with a patch version update is somewhat shocking. As a package maintainer, I generally assume such updates would solely fix bugs and otherwise maintain compatibility with the previous version. For openSUSE, I have been mulling over submitting 3.9.3 after reverting commit e4816de but am unsure if this will end up presenting new issues or not. Otherwise, since, as noted previously, even relatively recent NextCloud server versions — perhaps with specific configurations that nonetheless worked with 3.9.0 — I find it difficult to push 3.9.1/2/3 to the distro official repos. The use of an older owncloud server is a red herring as far as this bug goes. |
|
As someone who is/was having this problem, i'll add some more details: Our self-hosted Nextcloud (25.0.10) is behind an HA-Proxy and we use shibboleth for authentification. We fixed the problem for now by configuring our webserver to deliver 204 for the specific page that is used for the captive portal check. More a workaround than a solution imho. |
Agreed. Yet sometimes you have little influence on what servers others run. As long as it worked, it was better than running two clients, or old ones compromising security on my laptop. I'm OK with an update introducing new protocol constraints, but as said by @badshah400 I don't expect patch versions to break things that did work before. I'll remove the old ownCloud server. If otherwise it's a server/proxy config issue, this bug should be closed and support be moved to a new forum thread. |
|
Hit by this as well after an update to 3.9.3. Costed me a 2hr trip through the city as I didn't check whether the sync was successful before going to the office. As some others, I also am connected to a rather old server, but it's completely out of my control to change that. |
|
I'm affected as well, as the user of an institutional server I have no privileged access to. Is there a reason to believe that the server is misconfigured, without question? Then I could request a change from the admins, but I would need to justify this extra work to them. Until then I'll have to downgrade. |
|
@jhenin it is definitely a server configuration - we added a feature to handle captive portals now, but the way some servers do auth looks like a captive portal to the client. I think @allexzander can probably make the logic a little smarter perhaps. I personally think it's a great feature but I'm not using shibboleth or such ;-) I would suggest indeed to ping the sysadmins - #5929 (comment) has a solution. https://http.cat/status/204 does seem like an odd status code, indeed. I'd think a 511 is what is needed to show a portal, but anyhow, I'm no expert. I agree that, as a feature, this is weird to add to a minor release - though we do often add small things that were planned for the major a bit later, rather than waiting for a full new major. In any case, with 3.10.x out now, this point is moot in any case. With regards to "I do not control the server", I understand - I don't control our company server either. But, as a user, I would suppose you have some influence? After all, servers are run for users, not for the amusement of administrators. I would suggest at least to complain ;-) |
|
I was hit by this when moving from my old url domain.com/owncloud to domain.com/nextcloud Then it works for the desktop sync clients. (my mobile clients are still saying "Server unavailable" - can I get a hint for where to look?) |
Bug description
After updating to desktop client version 3.9.1 and restarting the client app, the app can no longer connect to the server and do any of the synchronisation activities with my local synced folder. The settings window says this at the very top: "Server is currently being redirected, or your connection is behind a captive portal." Neither is true: upon downgrading back to version 3.9.0, it immediately connects and resumes synchronisation with the same server with no change to my network status.
Please note that the hosting server is based on Owncloud 10.8.0.4, but using nextcloud-desktop for sync has not been an issue until version 3.9.0.
Steps to reproduce
Expected behavior
App should connect to server and synchronise as 3.9.0 does.
Which files are affected by this bug
Not applicable
Operating system
Linux
Which version of the operating system you are running.
openSUSE Tumbleweed
Package
Compiled it myself
Nextcloud Server version
Owncloud 10.8.0.4
Nextcloud Desktop Client version
3.9.1
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 3.4.2 to 3.4.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Enabled
Are you using an external user-backend?
Nextcloud Server logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: