I have Nextcloud Hub 10 (31.0.13) (not AOI) running via Docker on a Synology NAS device for a customer. All of their client machines run Windows 10 Pro and the official Nextcloud Desktop client has always worked fine on all of them until recently. I also can run the Desktop app on a desktop Linux workstation over the internet. Accounts occasionally would get signed out on some of the Win 10 Pro workstations (perhaps due to lack of consistent use), but signing back in was not a problem.
Recently two of the 5 workstations are refusing to connect to the server with the following error message:
The returned server URL does not start with HTTPS despite the login URL started with HTTPS. Login will not be possible because this might be a security issue. Please contact your administrator.
I always keep the server and clients up-to-date, and they are both the current version–Nexcloud Hub 10 version mentioned previously and Nextcloud (NC) Desktop for Windows version 4.0.5. The error above started appearing at version 4.0.4 and still appears after upgrading to 4.0.5. The error does not appear on the other 3 machines (all workstations and server are on the same network) neither when running 4.0.4 or 4.0.5. I’ve tried completely uninstalling NC Desktop on both machines (call them 2103 and 2105) and doing a fresh install of NC Desktop on them to no avail.
I’ve tried exporting debug information from them both, but the information in them isn’t very helpful to my eye.
I’m confused as to what is going on, but I suspect it is a conflict with another piece of software on the two machines. All of the machines are running Windows Defender + Norton without any special exceptions for Nextcloud desktop, so that should not be a problem. However, the biggest difference between the two machines having the problem and the other three is a massive application suite called Trimble Business. Both of them recently had upgrades to newer versions of the software and the license type changed. Right around the time of the upgrades is when Nextcloud started having problems.
I can’t uninstall Trimble to troubleshoot the issue because it’s a mission critical app for my customer’s business. Nextcloud is not as critical, but it would still be very helpful to figure out what’s causing the error I’m seeing on the two machines and getting it fixed.
I have two .zip files with exported debug info from Nextcloud Desktop that I’ve redacted the identifying info from. However, I cannot upload zip files here. How best can I share them so someone can review them to start seeing what’s going on? Beyond that, what can I do to further debug and troubleshoot this issue?
Good chances Im wrong… But could you try to perform this server side, when clients get refused :
occ security:bruteforce:reset
I’m thinking to this issue :
In my case, I had to whitelist IP on Nextcloud Administration, since every users connect from same IP. Only one client triggering it was getting all users banned by server.
I appreciate the response and apologize for the delayed reply. In moderate desperation and with a desire to try and fix the problem I ran the command on the server side without success. The command first returned telling me I needed to include an IP address at the end of the command. I complied and furnished both IPv4 and IPv6 of one of the client machines in question. However, it did not fix the issue.
It seems like there is some kind of communication happening from the client to the server because I see one or two (it seems only one, really) log lines in the server’s (Nextcloud specifically–I use Docker compose to run Nextcloud, Redis, Mariadb, and Nextcloud cron containers) logs with the IP address of the client machine, specifically the Link-local IPv6 Address. Since I don’t understand the intricacies of Nextcloud, IPv6, or how they both work together, I thought for a moment that might be part of the problem. However, I noticed other working client machines on the network are using their respective link-local IPv6 addresses without errors.
I’m still at a loss for how to troubleshoot this. I thought of trying packet sniffing (Wireshark), and I was able to sniff packets on one of the problem client machines, but I don’t know what I’m looking at or if that would even make any difference in understanding what is failing.
Once again, I would much appreciate any guidance in troubleshooting to actually understand the root problem better so that an effective solution can then be found either on my own or with additional assistance.