[Bug] The macOS client in Sequoia does not automatically connect to the server after the system has booted

[ismasans]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I have searched for it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

In macOS 15.7.5 Sequoia, when restarting or booting the system, the Nextcloud desktop client (version 33.0.4) fails to connect to the server.
Looking at the server logs, the following appears repeatedly: Login failed: '{8e347609-4b41-485f-a389-bc9a06341a60}' (Remote IP: 'XXX.XXX.XXX. XXX') every 30 seconds, and after about 10 attempts, the message TooManyRequests Exception thrown: OCA\DAV\Connector\Sabre\Exception\TooManyRequests appears.
This does not happen on another Mac running macOS Tahoe 26.4.1; I only encounter this issue on Sequoia.

Steps to reproduce

1. On macOS Sequoia
2. Set up and connect an account to the Nextcloud server using the macOS desktop client.
3. The client opens the browser to authorise the connection
4. The connection is successful and files synchronise as normal.
5. Restart the computer and log in to Finder
6. The Nextcloud client attempts to connect to the server but is unsuccessful.
7. On the server, in the Logging section of the Administration settings, Login failed warnings appear every 30 seconds and, after 10 attempts, TooManyRequests errors

Expected behavior

The client should connect to the server seamlessly after each restart.
I’ve been looking and have found these other issues, though I’m not sure if they’re related: #9794, #9865 and #9861.

Which files are affected by this bug

Client login on the server

Operating system

macOS

Which version of the operating system you are running.

Sequoia 15.7.5

Installation method

Official Installer for macOS 13 and later

Nextcloud Server version

33.0.3

Nextcloud Desktop Client version

33.0.4

Did this occur after an update or on a clean installation?

Clean desktop client installation

Are you using the Nextcloud Server Encryption module?

No

Are you using an external user-backend?

• Default internal user-backend
• LDAP or Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Additional info

I seem to recall that this issue was already resolved in a previous version of the Mac desktop client, but it has come back after updating the Nextcloud server from version 32 to version 33.0.3

[ismasans]

The previous issue I was referring to is #9761, which was supposedly resolved in #9773 with version 33.0.3.
Now, after updating the Nextcloud server to version 33.0.3, the problem has returned for me.

Edit: Well, the problem in those cases was that the client wouldn’t start up at login. Now the client does launch at startup but can’t connect to the server; it tries several times and the server blocks it.
If I disable “Launch at system startup” and open the Nextcloud client manually, it connects to the server correctly.

[ismasans]

Update: workaround found

After some investigation (with Claude's help) I believe the root cause is a timing issue between Tailscale and the Nextcloud client at startup. My Nextcloud server is only reachable via Tailscale (no port forwarding), and when the client launches automatically at login, it starts before Tailscale has established the VPN tunnel. The server is unreachable at that point, and the client enters a retry loop every ~30 seconds without recovering once Tailscale is up — hence the repeated Login failed entries and eventual TooManyRequests block.

This is consistent with what I reported in #9761, where the same symptom appeared with an earlier client version and was temporarily fixed in 33.0.3. It seems the regression introduced in the current versions (possibly related to the redirect policy change discussed in #9794 and PR #9861) has brought it back.

Note: this does not happen on macOS Tahoe 26.4.1 — only on Sequoia 15.7.x.

Workaround (macOS)

Disable "Launch on System Startup" in the Nextcloud client preferences, and instead use a launchd agent that opens the app with a 60-second delay, giving Tailscale enough time to connect first.

1. Create the file ~/Library/LaunchAgents/com.nextcloud.desktop.launcher.plist with this content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.nextcloud.desktop.launcher</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/sh</string>
        <string>-c</string>
        <string>sleep 60 && open -a Nextcloud</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

2. Load it (no restart needed):

launchctl load ~/Library/LaunchAgents/com.nextcloud.desktop.launcher.plist

After a reboot the client now connects successfully every time. 60 seconds may be more than needed depending on how fast Tailscale connects on your machine — 30 seconds might work too.

Hope this helps others with a similar setup while the underlying fix (PR #9861) makes it into a release.

[i2h3]

• In summary: This is not a problem of our client or something our client can resolve.
• This issue is not specific to any macOS release.
• I cannot see how Fix login flow by avoiding manual redirect policy on macOS client #9861 is related to this issue.
• If the server responds like in the initial description (HTTP standard response for too many requests), the client simply cannot connect and there is nothing to do about it because the server refuses to serve for the literal reason and a possibly enabled DDoS or brute-force protection.
• The client connects as expected if the server does not reject it and the underlying network infrastructure is ready. The latter is a lower level. Our app-layer client is not responsible for that and cannot influence it.
• Tailscale is a third-party VPN and network solution we are not responsible for. In general, like most other software, we cannot add complexity in our own to make up for the problems other products create. That will become a bottomless pit.
• The suggested workaround is suitable only for comparable setups and the same problem and will counteract the interests of the majority of our user base by delaying the client readiness on boot.