Skip to content

macOS FileProvider reports "NotAuthenticated" although Nextcloud Desktop Client is connected #10885

Closed
Bug
#10894
Closed
macOS FileProvider reports "NotAuthenticated" although Nextcloud Desktop Client is connected#10885
Bug
#10894
Assignees
claucambra
Labels
0. Needs triagefeature: 📁 file providermacOS File Provider Extension, more general also known as virtual file system.os: 🍎 macOSApple macOS, formerly also known as OS X

Description

@3ueb
3ueb
opened on Sep 21, 2026

Environment

  • Nextcloud Desktop Client: 34.0.4
  • macOS: 27
  • Mac architecture: Apple Silicon (arm64)
  • Nextcloud Server: 34.x
  • FileProvider extension: com.nextcloud.desktopclient.FileProviderExt
  • macOS FileProvider is enabled and registered
  • The Nextcloud Desktop Client itself reports that the account is connected/authenticated.

Problem

The Nextcloud Desktop Client shows the account as connected, but the macOS FileProvider extension repeatedly reports that the account is not authenticated.

The Nextcloud folder is registered as a FileProvider domain and appears in ~/Library/CloudStorage/, but macOS cannot access the FileProvider items.

fileproviderctl dump reports:

domain: com.nextcloud.desktopclient.FileProviderExt/...
    spDomainID: ECCD47A9-42DB-4E75-8C03-4583DE272987
    needs-auth: yes

The FileProvider daemon repeatedly reports:

FP -1000 "You must authenticate before accessing this object."

The Nextcloud FileProvider extension log contains:

FileProviderExt: (FileProvider) [com.apple.FileProvider:default] [ERROR]
Creating internal error for "itemForItemID", original error was:
NSError: FP -1000 "<private>"

The extension then resolves the error as:

key: NotAuthenticated
value: You must authenticate before accessing this object.

Relevant FileProvider state

The Nextcloud domain is present:

domain: com.nextcloud.desktopclient.FileProviderExt/...
root: <FPFS>/N{38}z.link-uwe
needs-auth: yes

The domain is otherwise active and the FileProvider extension is loaded:

bundle URL:
/Applications/Nextcloud.app/Contents/PlugIns/FileProviderExt.appex

containing bundle identifier:
com.nextcloud.desktopclient

The FileProvider database and domain are also present.

Additional observations

The Nextcloud server log shows regular DAV requests from the desktop client, for example:

method: PROPFIND
url: /remote.php/dav/files/uwe/

The server also logs warnings such as:

The app config key dav/enableCalendarFederation is not defined in the config lexicon

and:

The app config key dav/sendInvitations is not defined in the config lexicon

These warnings occur during normal DAV requests and do not appear to explain the FileProvider authentication failure.

The macOS FileProvider log also initially reported:

Not fetching item because account was never set up.
- item: NSFileProviderRootContainerItemIdentifier

The Nextcloud Desktop Client nevertheless reports the account as connected.

Everthing works with the Windows File Explorer

Expected behavior

When the Nextcloud Desktop Client account is connected/authenticated, the corresponding FileProvider domain should also be authenticated and accessible through macOS Finder/FileProvider.

fileproviderctl dump should not report:

needs-auth: yes

and FileProvider should not repeatedly return:

FP -1000
NotAuthenticated

Actual behavior

The Nextcloud Desktop Client reports that the account is connected, but the FileProvider domain remains in an unauthenticated state:

needs-auth: yes

This causes repeated FileProvider errors and prevents normal access to the Nextcloud CloudStorage folder.

Reproduction

  1. Install Nextcloud Desktop Client 34.0.4 on macOS 27.
  2. Configure a Nextcloud account.
  3. Verify that the Nextcloud Desktop Client reports the account as connected.
  4. Verify that the Nextcloud FileProvider domain exists.
  5. Run: fileproviderctl dump | grep -E "domain:|spDomainID:|root:|needs-auth:|error:"
  6. Observe:
domain: com.nextcloud.desktopclient.FileProviderExt/...
needs-auth: yes
  1. The macOS log repeatedly reports:
FP -1000
NotAuthenticated

Question

Could this be an issue with the authentication/credential hand-off between the Nextcloud Desktop Client and the macOS FileProvider extension?

In particular, is the FileProvider extension expected to obtain or refresh its authentication state independently from the main Nextcloud Desktop Client?

The behavior suggests that the main client has a valid authenticated session while the FileProvider extension has either no valid credentials or is unable to access/refresh them.

I would appreciate any guidance on how to reset or reinitialize the FileProvider authentication state without deleting the local Nextcloud data.

Activity

  1. Rello
    added
    os: 🍎 macOSApple macOS, formerly also known as OS X
    feature: 📁 file providermacOS File Provider Extension, more general also known as virtual file system.
    on Sep 21, 2026
  2. Rello
    added the
    Bug
    issue type on Sep 21, 2026
  3. Rello
    added
    0. Needs triage
    on Sep 21, 2026
  4. claucambra
    self-assigned this
    on Sep 22, 2026

  5. Skulli commented on Sep 26, 2026

    @Skulli
    Skulli
    on Sep 26, 2026

    Same symptoms here (34.0.4, macOS 26.7 25G229, Apple Silicon). In my case the root cause was macOS Local Network privacy: the server hostname resolves to a private LAN IP, and the extension is blocked even though Nextcloud has Local Network permission:

    FileProviderExt … failed path (unsatisfied (Local network prohibited) …)
FileProviderExt … HTTP load failed … (error code: -1009)
FileProviderExt … Not fetching item because account was never set up.

    Started right after the macOS 26.7 update. Workaround: point the hostname to the public IP via /etc/hosts (NAT loopback) so the extension can finish its initial setup; after removing the entry again it keeps working on the LAN IP.

    @3ueb does your server resolve to a local IP? Check with:
    log show --last 5m --predicate 'process CONTAINS "FileProviderExt"' | grep "Local network prohibited"

    Drafted with AI assistance (Claude); logs and findings are from my own system.

  6. claucambra
    closed this as completedin #10894on Sep 28, 2026

  7. 3ueb commented on Sep 28, 2026

    @3ueb
    3ueb
    on Sep 28, 2026
    Author

    @Skulli
    I added the router’s public IPv6 address, including the port forwarding, to the hosts file. I also tried using the LAN IPv4 address, but unfortunately, neither approach helped so far.

  8. JBelliriGenty commented on Oct 3, 2026

    @JBelliriGenty
    JBelliriGenty
    on Oct 3, 2026

    Same issue here, and I can add a precise root cause from the macOS network logs: the File Provider extension is blocked by macOS Local Network privacy, even though the Nextcloud app itself is allowed in Privacy & Security → Local Network.

    Environment

    • macOS 27.0 (Apple Silicon, Mac Studio)
    • Nextcloud desktop client 34.0.4 (official build, Qt 6.10.2, OpenSSL 3.6.3), File Provider mode (macFileProviderModeEnabled=true)
    • Nextcloud server 34.0.4 behind a reverse proxy, HTTPS with a valid public certificate
    • On the LAN, the server hostname resolves (split-horizon DNS) to a private RFC 1918 address of the reverse proxy

    Symptoms

    • The main client is connected and syncs normally (DAV requests succeed, visible in the reverse proxy logs).
    • Finder → Locations → Nextcloud shows "disconnected" / "you need to authenticate".
    • The reverse proxy never receives a single request from the extension.

    Extension log (FileProviderExt)

    [FileProviderExtension] Setting up domain account for user: <user>, serverUrl: https://cloud.example.org, password: <not-empty>
[FileProviderExtension] Authentication try timed out. Trying again soon.
[FileProviderExtension] Not fetching item because account was never set up.

    macOS network log (log show --predicate 'process == "FileProviderExt"')

    FileProviderExt: [com.apple.network:connection] [C5.1.1.1 IPv4#<redacted>:443 waiting path (unsatisfied (Local network prohibited), interface: en1[802.11], ipv4, uses wifi, flow divert agg: 2)] event: path:unsatisfied @0.013s
FileProviderExt: [com.apple.network:connection] [C5 Hostname#<redacted>:443 ...] reporting state failed error Network is down
FileProviderExt: [com.apple.CFNetwork:Default] Task <...> HTTP load failed, 0/0 bytes (error code: -1009 [1:50])
FileProviderExt: [com.apple.CFNetwork:Default] Task <...> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009
FileProviderExt: [FileProviderExtension] Authentication try timed out. Trying again soon.

    The request fails in ~15 ms, before any TCP connection, with Local network prohibited.

    fileproviderctl dump com.nextcloud.desktopclient.FileProviderExt

    needs-auth:     yes
i:root create-item: ... error:'NSError: FP -1000 "You need to authenticate before accessing this item."' domain:auth
i:.root fetch-event-stream: ... error:'NSError: FP -1004 ... NSLocalizedFailureReason=Nextcloud application has been closed. Reopen to reconnect., NSFileProviderErrorDomainDisconnectionStateKey=3' domain:serverUnreachable

    What was tried (none fixed it)

    • Privacy & Security → Local Network: only "Nextcloud" is listed (no separate FileProviderExt entry), and it is enabled. Toggled off/on.
    • Quit client → reboot → launch client from Applications (order from the community "solved" thread), several times.
    • Uninstall/reinstall of the client; full reboot.
    • The server is reachable from the same Mac by the main app, browsers and curl; the TLS chain is valid.

    Analysis

    The extension does not seem to inherit the Local Network permission granted to the containing app on macOS 27, and macOS never shows a separate prompt (or Settings entry) for the extension. Any server reached through a private/local address is therefore unreachable for the File Provider, while the main client works, which matches the "connected but NotAuthenticated" state reported here.

    Possibly related: missing NSLocalNetworkUsageDescription in the extension's Info.plist, or the extension's network activity not being attributed to the host app on macOS 27.

    Workaround confirmed in principle: when the server is reached through a non-local address (public IP via NAT loopback), the restriction does not apply. That is not acceptable for most self-hosted setups.

    Happy to provide more logs or test a build.

  9. 3ueb commented on Oct 11, 2026

    @3ueb
    3ueb
    on Oct 11, 2026
    Author

    Hello,

    I am not sure why this ticket was closed, but the issue persists with macOS 27.0.1 and Nextcloud 34.0.5.

  10. claucambra commented on Oct 12, 2026

    @claucambra
    claucambra
    on Oct 12, 2026
    Collaborator

    Hi @3ueb we fixed one source of such an issue via the pull request linked to this issue. It is possible that there are other problem paths that can manifest the same way (e.g. #10996 )
    Is it possible you are running your instance on the same local network as the Mac you are running the client on?

  11. 3ueb commented on Oct 17, 2026

    @3ueb
    3ueb
    on Oct 17, 2026
    Author

    Hi @claucambra, yes I am running the instance on the sam e local network as the Mac. And I use the port forwarding functionality of my FRITZ!Box.

  12. claucambra commented on Oct 29, 2026

    @claucambra
    claucambra
    on Oct 29, 2026
    Collaborator

    Okay @3ueb then I will keep this issue closed as it is the same as #10996
    Good news is that we just merged a fix for this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

0. Needs triagefeature: 📁 file providermacOS File Provider Extension, more general also known as virtual file system.os: 🍎 macOSApple macOS, formerly also known as OS X

Type

Bug

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions