Skip to content

[Bug]: Menu bar icon disappears on large multi account file sync in macOS #9944

@potanin

Description

@potanin

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

Bug description

Hello,

I have been experiencing consistent crashes for the Nextcloud macOS client over the last week when trying to synchronise a large number of files (200,000 photos) to my server. I have been stumped as to why and resorted to asking Claude to see if he can figure out what I am doing wrong. It looked at the diag files I am getting and the logs and suggested some bug I do not fully understand, but maybe you can find it helpful. Feel free to ignore, as it is AI-assisted, but the crashes are real, and I see them. As far as I can tell, the diag and log samples don't contain my private info, so I hope these help, and I hope Claude's thing was onto something real, not fake. ;-)

Cheers,
Alex.

--- CLAUDE FROM HERE ---

Bug description

The macOS GUI process spends ~96% of sampled time in a tight loop polling AppleInterfaceStyle (dark/light mode preference) via CFPrefsPlistSource, combined with QSettings::sync() calls from QtNetwork that take a QLockFile and write to disk. This saturates the main UI thread, dirties ~8.6 GB of file-backed memory in 11 hours, and triggers macOS resource-budget diagnostic reports.

User-visible symptoms include:

  • The menu bar icon becomes unresponsive or disappears entirely while File Provider extensions continue syncing in the background
  • Activity panel ceases updating
  • App appears to "crash" but is actually thrashing — killall Nextcloud and relaunch is the only recovery
  • macOS files Nextcloud_*_kanga.diag reports under /Library/Logs/DiagnosticReports/ for excessive disk writes
  • Footprint grows from ~67 MB at launch to >1.6 GB within ~14 minutes of sampling

This may be the underlying cause of several existing reports, including #9137, #7377, #7692, #6139, and #5121. Filing separately because none of those identifies the AppleInterfaceStyle + QSettings::sync pattern as the root cause.

Steps to reproduce

  • Configure Nextcloud Desktop with multiple accounts (in my case, 5).
  • Enable File Provider mode (macOS-native virtual files).
  • Begin initial sync of a large library (in my case, ~213k photos on the server side).
  • Observe the GUI within 10 minutes.

IMPORTANT: My workaround is to disable sync for all 5, then enable it on JUST ONE. It seems to run for a little longer, but eventually, after 20-30 minutes, it crashes. :-)

BUT, only the GUI process crashes; these stay:

% ps aux | grep -i nextcloud | grep -v grep | head -5
alex 18875 0.0 0.1 442672576 35152 ?? Ss Thu07PM 1:08.44 /Applications/Nextcloud.app/Contents/PlugIns/FileProviderExt.appex/Contents/MacOS/FileProviderExt -LaunchArguments eyJ0eXBlIjoxLCJlbmhhbmNlZFNlY3VyaXR5IjpmYWxzZSwic2VydmljZU5hbWUiOiJjb20ubmV4dGNsb3VkLmRlc2t0b3BjbGllbnQuRmlsZVByb3ZpZGVyRXh0In0=
alex 18874 0.0 0.1 442657552 35152 ?? Ss Thu07PM 1:35.84 /Applications/Nextcloud.app/Contents/PlugIns/FileProviderExt.appex/Contents/MacOS/FileProviderExt -LaunchArguments eyJ0eXBlIjoxLCJlbmhhbmNlZFNlY3VyaXR5IjpmYWxzZSwic2VydmljZU5hbWUiOiJjb20ubmV4dGNsb3VkLmRlc2t0b3BjbGllbnQuRmlsZVByb3ZpZGVyRXh0In0=
alex 18873 0.0 0.1 442677952 35184 ?? Ss Thu07PM 1:07.06 /Applications/Nextcloud.app/Contents/PlugIns/FileProviderExt.appex/Contents/MacOS/FileProviderExt -LaunchArguments eyJ0eXBlIjoxLCJlbmhhbmNlZFNlY3VyaXR5IjpmYWxzZSwic2VydmljZU5hbWUiOiJjb20ubmV4dGNsb3VkLmRlc2t0b3BjbGllbnQuRmlsZVByb3ZpZGVyRXh0In0=
alex 18872 0.0 0.1 442874544 39008 ?? Ss Thu07PM 1:06.94 /Applications/Nextcloud.app/Contents/PlugIns/FileProviderExt.appex/Contents/MacOS/FileProviderExt -LaunchArguments eyJ0eXBlIjoxLCJlbmhhbmNlZFNlY3VyaXR5IjpmYWxzZSwic2VydmljZU5hbWUiOiJjb20ubmV4dGNsb3VkLmRlc2t0b3BjbGllbnQuRmlsZVByb3ZpZGVyRXh0In0=
alex 18871 0.0 0.1 443021264 45488 ?? Ss Thu07PM 2:12.27 /Applications/Nextcloud.app/Contents/PlugIns/FileProviderExt.appex/Contents/MacOS/FileProviderExt -LaunchArguments eyJ0eXBlIjoxLCJlbmhhbmNlZFNlY3VyaXR5IjpmYWxzZSwic2VydmljZU5hbWUiOiJjb20ubmV4dGNsb3VkLmRlc2t0b3BjbGllbnQuRmlsZVByb3ZpZGVyRXh0In0=
alex@MacBookPro ~ %

Expected behavior

--- AGAIN FROM CLAUDE THINGAMEJIG ---

The GUI should remain responsive, the menu bar icon should stay visible, and the app should not consume resources at a rate that triggers macOS resource-budget warnings.

The AppleInterfaceStyle preference should be observed via NSDistributedNotificationCenter's AppleInterfaceThemeChangedNotification rather than polled. QSettings::sync() should not run on the main thread on every QtNetwork operation completion.

Actual behavior

From log stream --predicate 'process == "Nextcloud"' --info --debug (sample attached)

The Nextcloud process emits this pair of messages 30-40 times per second, indefinitely:

Nextcloud: (CoreFoundation) [com.apple.defaults:User Defaults] looked up value <private> for key AppleInterfaceStyle in CFPrefsPlistSource<...> (Domain: kCFPreferencesAnyApplication, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No) via CFPrefsSearchListSource<...> (Domain: com.nextcloud.desktopclient, Container: (null) Non-launch persona: 0)
Nextcloud: (FrontBoardServices) [com.apple.FrontBoard:SceneClient] [com.apple.controlcenter:...] Sending action(s) in update: NSSceneFenceAction

The NSSceneFenceAction between each query indicates a UI redraw cycle is being forced on each poll.

From Nextcloud_2026-05-01-144224_kanga.diag (attached)

macOS resource-budget diagnostic report:

Event:            disk writes
Writes:           8589.94 MB of file backed memory dirtied over 39317 seconds
                  (218.48 KB per second average), exceeding limit of 99.42 KB per second
                  over 86400 seconds
Footprint:        67.44 MB -> 1640.97 MB (+1573.53 MB)

Heaviest stack (201/209 samples) for the main thread:

QCoreApplication::exec()
  → QEventLoop::exec(...)
  → libqcocoa.dylib (NSApplication event loop)
  → QApplicationPrivate::notify_helper(...)
  → QObject::event(...)
    → QtNetwork (×90 samples, multiple offsets)
    → QSettings::sync()
    → QLockFile::tryLock(...)
    → write() syscall

This indicates that QtNetwork is invoking QSettings::sync() on completion of network operations, on the main thread, which acquires a lock file and performs a synchronous write repeatedly, for every network operation.

Server configuration
(Omitted — issue is purely client-side and may reproduce against any server.)

Client configuration

Nextcloud Desktop: 33.0.3 (33.0.3.0)
Operating system: macOS 26.4.1 (Build 25E253)
Hardware: MacBook Pro 18,4 (M1 Max), 64 GB RAM, arm64
Installation: Direct download (Team ID: NKUJUXUJ3B, signed by Nextcloud GmbH)
Mode: File Provider (macOS-native virtual files)
Accounts configured: 5 (one primary, four secondary all paused in GUI)
File Provider extensions running: 4 (one per non-primary account, persistent across GUI restarts)

nextcloud-diag.zip
nextcloud-log-sample.txt

Logs

Two files attached:

nextcloud-diag.zip — full .diag report from /Library/Logs/DiagnosticReports/
nextcloud-log-sample.txt — ~10 seconds of log stream output showing the polling loop

Additional context — possible related issues

#9137 — Menu bar icon no longer shows sync status (likely surface symptom of GUI being unresponsive)
#9724 — Memory leak / infinite loop pattern (different specific trigger, similar shape)
#7377 — macOS becomes unresponsive at 100% CPU (likely same root cause)
#7692 — Status icons missing when other File Providers active (related: this report has 4 File Provider extensions active)
#6139 — No icon in menu bar with extensions still running (matches my "icon disappears" symptom)
#5121 — Menu unresponsive, only killall Nextcloud recovers (matches recovery pattern)

Suggested investigation areas

  1. Theme change detection — replace any polling-based reads of AppleInterfaceStyle with subscription to NSDistributedNotificationCenter's AppleInterfaceThemeChangedNotification.

  2. QtNetwork → QSettings interaction — investigate why network operation completion triggers QSettings::sync(). Likely candidate: cookie jar persistence, OAuth token storage, or QNetworkAccessManager configuration. Move to a worker thread or batch writes.

  3. Multi-account scaling — the load is N× per active account. Investigate whether shared state can be centralized.

Which files are affected by this bug

None

Operating system

macOS

Which version of the operating system you are running.

Tahoe 26.4.1

Package

Official macOS 12+ universal pkg

Nextcloud Server version

32.0.8.2

Nextcloud Desktop Client version

33.0.3.0

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.16.1 to 3.16.2)

Are you using the Nextcloud Server Encryption module?

Encryption is Enabled

Are you using an external user-backend?

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

Nextcloud Server logs

Additional info

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No fields configured for Bug.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions