MacOS Files client 34.0.4 crashing almost instantly

jmax · September 24, 2026, 6:40am

I’m setting up a brand new NextCloud – I have server 33.0.0 running on webhosting, and I’m having a terrible time with the NC FIles client v34.0.4 for arm64 for MacOS (Tahoe 26.3.1).

The client launches, and I can get through the authentication to the server – it even shows me whats sync’ed, but then the client just dies. Within a few seconds. So fast that I can’t even get to the account settings before it dies.

Now… I had an older version configured on this machine – a v33 client connecting to an old v30 server, and I did my best to root out all of that old config and folders. But perhaps that’s part of the trouble?

I thought maybe I could uninstall this new client – but I can’t even seem to do that, now that Apple has integrated cloud services in the OS – the piece at ~/Library/CloudStorage/NextCloud is locked down so hard I can’t delete it (not even sudo allows me to take that folder out!).

I’m stuck here. How the heck to even uninstall NextCloud from my Mac??? And what is up with the crashing. NextCloud has always been so solid!

iva.horn · September 24, 2026, 8:17am

Hi, @jmax !

Have you already consulted our documentation on how to cleanly uninstall the client on macOS? I recommend an additional reboot of your Mac afterwards, just to be sure.
Can you check the macOS “Console” app for crash reports in its equally named section in the sidebar? Does “Nextcloud” or “FileProviderExt” show up?
The (apparent) folder in ~/Library/CloudStorage indeed is not just an ordinary folder. How macOS manages file provider domains internally is a bit more complicated. It is correct that those cannot be simply deleted, usually. macOS has kind of a database itself which backs that domain and it can sometimes get messed up. Anyway, when you have a clean environment and the client launches, it will check for orphaned file provider domains and delete them to restore a clean environment. This can only be done by apps which have an identity corresponding to what created the file provider domains. Doesn’t this happen after you cleaned up your installation as documented above?

jmax · September 24, 2026, 6:45pm

Hi, Iva, thanks very much for the info and help.

I went in and dug out everything that the Docs say needs to be removed for a MacOS uninstall. Then I rebooted twice and made sure nothing was leftover… no mention of NextCloud in my Login Items/extensions, for instance.

Installed fresh 34.0.4 client; launched it, and was prompted to authenticate, which it apparently did successfully, as I got the “Up to date and connected” icon in my menubar. But then about 2 seconds later, it crashed.

In console, there are a series of Crash reports (one today,and a bunch yesterday). They all look more or less like this one (see below for the beginning of the report, before it goes to really gory details about individual threads.

Translated Report (Full Report Below)

Process: Nextcloud [1173]
Path: /Applications/Nextcloud.app/Contents/MacOS/Nextcloud
Identifier: com.nextcloud.desktopclient
Version: 34.0.4 (34.0.4.0)
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.nextcloud.desktopclient [1175]
User ID: 501

Date/Time: 2026-09-24 11:36:08.7627 -0700
Launch Time: 2026-09-24 11:34:45.3412 -0700
Hardware Model: Mac16,12
OS Version: macOS 26.3.1 (25D771280a)
Release Type: User

Crash Reporter Key: 62838A84-ABF4-A8AB-FAA2-E5D44B409FBF
Incident Identifier: ADD4D2F4-E3BA-47B8-915A-387D1D306B95

Time Awake Since Boot: 470 seconds

System Integrity Protection: enabled

Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000008
Exception Codes: 0x0000000000000001, 0x0000000000000008

Termination Reason: Namespace SIGNAL, Code 11, Segmentation fault: 11
Terminating Process: exc handler [1173]

VM Region Info: 0x8 is not in any region. Bytes before following region: 4372381688
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
—>
__TEXT 1049d4000-104fa0000 [ 5936K] r-x/r-x SM=COW /Applications/Nextcloud.app/Contents/MacOS/Nextcloud

Thread 0 Crashed:: 0 QtCore 1 QtNetwork 2 QtNetwork 3 QtNetwork 4 QtNetwork 5 QtNetwork 6 libnextcloudsync.0.dylib 7 Nextcloud 8 QtNetwork 9 libnextcloudsync.0.dylib 10 libnextcloudsync.0.dylib 11 libnextcloudsync.0.dylib 12 libnextcloudsync.0.dylib 13 libnextcloudsync.0.dylib 14 libnextcloudsync.0.dylib 15 Nextcloud 16 Nextcloud 17 Nextcloud 18 Nextcloud 19 QtCore 20 QtWidgets 21 QtCore 22 QtGui 23 AppKit 24 AppKit 25 AppKit 26 AppKit 27 AppKit 28 AppKit 29 AppKit 30 AppKit 31 AppKit 32 AppKit 33 AppKit 34 AppKit 35 AppKit 36 AppKit 37 AppKit 38 libqcocoa.dylib 39 libqcocoa.dylib 40 QtCore 41 QtCore 42 Nextcloud 43 dyld Dispatch queue: com.apple.main-thread
0x108c0f5f0 QUrl::QUrl(QUrl const&) + 0
0x105878668 QHstsPolicy::QHstsPolicy(QHstsPolicy const&) + 52
0x105877bb0 0x10586c000 + 48048
0x1058e6450 0x10586c000 + 500816
0x105876280 0x10586c000 + 41600
0x105884234 QNetworkAccessManager::createRequest(QNetworkAccessManager::Operation, QNetworkRequest const&, QIODevice*) + 1548
0x105b93410 OCC::AccessManager::createRequest(QNetworkAccessManager::Operation, QNetworkRequest const&, QIODevice*) + 1400
0x104c6fa0c 0x1049d4000 + 2734604
0x105882dec QNetworkAccessManager::get(QNetworkRequest const&) + 36
0x105afeb0c OCC::Account::sendRawRequest(QByteArray const&, QUrl const&, QNetworkRequest, QIODevice*) + 216
0x105ba7eb8 OCC::AbstractNetworkJob::sendRequest(QByteArray const&, QUrl const&, QNetworkRequest, QIODevice*) + 96
0x105bb99a4 OCC::SimpleApiJob::start() + 552
0x105bb96d8 OCC::JsonApiJob::start() + 212
0x105cd169c OCC::OcsUserStatusConnector::startFetchUserStatusJob() + 496
0x105cd12a8 OCC::OcsUserStatusConnector::fetchUserStatus() + 248
0x104c4df64 OCC::User::slotRefreshUserStatus() + 92
0x104c4572c OCC::User::slotRefresh() + 40
0x104b54118 OCC::Systray::showTrayPopup(OCC::Systray::WindowPosition) + 140
0x104b18af4 OCC::ownCloudGui::slotTrayClicked(QSystemTrayIcon::ActivationReason) + 472
0x108c7f650 0x108b94000 + 964176
0x1065953c0 0x1064f0000 + 676800
0x108c7f69c 0x108b94000 + 964252
0x108157758 QPlatformSystemTrayIcon::activated(QPlatformSystemTrayIcon::ActivationReason) + 60
0x1971650c8 -[NSApplication(NSResponder) sendAction:to:from:] + 560
0x196f129f4 -[NSControl sendAction:to:] + 72
0x197150dd0 -[NSStatusBarButtonCell _sendActionFrom:] + 156
0x196f167bc __NSControlTrackMouse_block_invoke + 40
0x196760310 NSControlTrackMouse + 656
0x196efc790 -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 144
0x196eeeba0 -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 232
0x1971504c4 -[NSStatusBarButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 412
0x196f18838 -[NSControl(_NSTracking) _mouseDown:] + 612
0x196f185a8 -[NSControl(_NSTracking) mouseDown:] + 104
0x19742cb80 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3676
0x1974299f8 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 492
0x197429488 -[NSWindow(NSEventRouting) sendEvent:] + 372
0x197158344 -[NSStatusBarWindow sendEvent:] + 892
0x197161a5c -[NSApplication(NSEventRouting) sendEvent:] + 1276
0x107f83a28 0x107f7c000 + 31272
0x107f91060 0x107f7c000 + 86112
0x108c36794 QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 588
0x108c2d494 QCoreApplication::exec() + 228
0x1049e277c main + 2832
0x191e19d54 start + 7184

iva.horn · September 24, 2026, 7:52pm

Okay, odd. This possibly is rooted in your server setup which the client is not prepared to handle correctly. I need to do research on this…

iva.horn · September 25, 2026, 10:44am

@jmax As off now, it looks like a problem in the underlying network layer of Qt which is the framework we use for the client. It might also be a misconfigured server. Can you provide the output of this Terminal command? It should clarify what HSTS header the server sends.

curl -sS -o /dev/null -D - "https://<server>/status.php" | grep -i strict-transport

Who hosts it? Is there a CDN or reverse proxy in front (Cloudflare etc.)? Is HSTS set in a hosting panel (Plesk, cPanel) or in .htaccess?

The client crashes on every launch, right?

jmax · September 25, 2026, 5:48pm

Thanks so much, Iva,

Yes, it crashes on every launch. Except when it was brand new and I hadn’t made the server connection yet.

A misconfigured server shouldn’t completely kill the client, though, should it? I can confirm that the NextCloud client on my Android phone connects perfectly; I can download and upload files, no problems at all. But anyway…

The server is hosted by ReclaimHosting on their cloud service (Jelastic PaaS, afaik) Pretty sure there’s a Cloudflare layer in there too. It’s pretty locked down, security-wise; when I ssh in, I’m walled off entirely from the workings, so I can’t see anything there.

However, poking around the web interfaces turned up two pieces of relevant info:

The Admin panel in my NextCloud server says:

Some headers are not set correctly on your instance - The `Strict-Transport-Security` HTTP header is not set to at least `15552000` seconds (current value: `5`). For enhanced security, it is recommended to use a long HSTS policy.

And, the logs I can access in NextCloud’s Admin panel have these three lines, which do seem to coincide with my crashing:

Error		core		ExceptionHMAC does not match.	24 Sept 2026, 11:35:28
	
Error		core		ExceptionHMAC does not match.	23 Sept 2026, 16:02:31
	
Error		core		TransportExceptionUnable to connect with STARTTLS: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: error:0A000086:SSL routines::certificate verify failed	23 Sept 2026, 15:59:49

Response from the curl command (local, on the client side) you suggested is this:

content-security-policy: default-src ‘self’; script-src ‘self’ ‘nonce-VZIrIHO5mAL3g0rIvNJz6zIfAIFnhtxdbcJMx7ECYkM=’; style-src ‘self’ ‘unsafe-inline’; frame-src *; img-src * data: blob:; font-src ‘self’ data:; media-src *; connect-src *; object-src ‘none’; base-uri ‘self’;
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=5; includeSubDomains

I can try to dig deeper if I know what I’m looking for! Thank you again!

iva.horn · September 28, 2026, 8:08am

This is a bug on the client side. It’s in the Qt library the desktop client uses for HSTS. With max-age=5, the client’s saved HSTS entry expires 5 seconds after each server response, and the next request after that crashes the client. The Android app doesn’t use this code, by the way.

Workaround until we ship a fix: ask ReclaimHosting to set the Strict-Transport-Security max-age to at least 15552000, which is what the Nextcloud admin check recommends, or to remove the header. Unfortunately there’s nothing you can do on the client side. Reinstalling or clearing caches won’t help while the server keeps sending max-age=5.

If it helps them find where the header is set, this shows whether Cloudflare or their own proxy is answering:

curl -sS -o /dev/null -D - "https://<your-server>/status.php" | grep -iE '^(server|cf-ray|strict-transport)'

The other log entries aren’t related to the crash. The STARTTLS error is about the server’s outgoing mail settings. The HMAC error is also on the server side and doesn’t affect the desktop client.

We had a report about this problem in the past already. I now opened a new issue to track for this problem.

jmax · September 29, 2026, 8:35pm

Thanks so much, Iva,

The workaround (max-time set to a much larger number) has been implemented, and the MacOS client 34.0.4 has been stable for 15 minutes or so… and fully functional as far as I can tell so far!

Excellent support! Thanks!

iva.horn · September 30, 2026, 11:52am

I am glad this was easy to clear up and resolve.

By the way: my colleague Claudio worked on a fix in our client and even opened a pull request at Qt to resolve the root cause.