[Bug]: "Remove download" fails with EBUSY after Quick Look preview (macOS File Provider)

[pixelastronauts]

[Bug]: "Remove download" fails with EBUSY after a file has been previewed with Quick Look (macOS File Provider)

⚠️ Before submitting

• I checked for existing issues ([Bug]: MacOS Client with VFS: Sometimes files are not evicted randomly #7832, [Bug]: Macos - Can't evict more than 10 files (or items) in a row. #9757, "Remove Download" unavailable on folders #10085, "Remove download" option missing randomly for materialised files/folders in v34.0.0 #10517, macOS File Provider: “Remove Downloaded Items” only partially evicts folders and is missing for some downloaded files #10555 — related symptoms, none identifies this cause)
• I can reproduce this reliably

Summary

On macOS, once a file inside the File Provider domain has been previewed with Quick Look (spacebar in Finder), "Remove download" on that file fails permanently. The Finder dialog shown is:

Geen communicatie met een helperapp mogelijk.
Probeer de bewerking opnieuw uit te voeren. Als dat mislukt, stop je de app, start je de app opnieuw en probeer je het nogmaals.

(EN: "Unable to communicate with a helper application.")

The underlying failure is POSIX 16 (EBUSY) from fileproviderd, because QuickLookUIService leaves an NSFilePresenter registration on the item after the preview window is closed. The registration is not released on window close and is not released by SIGTERM to the service. Only kill -9 on QuickLookUIService clears it, after which eviction succeeds immediately.

This is almost certainly the unexplained "random" eviction failure reported in #7832.

Steps to reproduce

1. macOS client with Virtual Files / File Provider enabled.
2. In Finder, navigate to a materialised (downloaded) file in the Nextcloud domain — reproduced with a .mp4, but not file-type specific.
3. Select the file and press spacebar to open Quick Look.
4. Close the Quick Look window.
5. Right-click the file → Remove download.

Expected behaviour

The local copy is evicted and the file becomes a placeholder.

Actual behaviour

Eviction fails with the "Geen communicatie met een helperapp mogelijk" dialog. It fails on every retry, indefinitely. Files in the same folder that were never previewed evict without any problem.

Workaround:

kill -9 $(pgrep -x QuickLookUIService)

After this the exact same "Remove download" succeeds immediately.

Evidence

fileproviderd error at the moment of the failed eviction:

2026-08-13 13:48:43.736619+0200  Error  fileproviderd: (FileProviderDaemon)
[com.apple.FileProvider:com.nextcloud.desktopclient.FileProviderExt/…]
Eviction of docID(2167678) failed with NSError: POSIX 16 "<private>"

fileproviderctl dump com.nextcloud.desktopclient.FileProviderExt, taken with no Quick Look window open:

presenter for S…0.mp4 (__fp/fs/docID(2167678)) by QuickLookUIService[83461]

+ active enumerators:
    <fpfs:docID(2167678)   requestedBy:83461 hasPresenter:yes>
    <fpfs:root             requestedBy:83453 hasPresenter:no>
    <fpfs:trash            requestedBy:83453 hasPresenter:no>
    <fpfs:fileID(26596354) requestedBy:83453 hasPresenter:no>
    …

presenter: QuickLookUIService[83461] presenting <FPFS>/…/S…0.mp4
  (com.nextcloud.desktopclient.FileProviderExt/…/__fp/fs/docID(2167678))

docID(2167678) is exactly the item that failed to evict. The presenter is scoped to the single previewed file — all other items report hasPresenter:no, so eviction of the parent folder is unaffected.

Notes:

• lsof shows nothing for the path. The presenter is an XPC-level NSFilePresenter registration, not a POSIX file descriptor, so the usual "what's holding this file" check comes back clean and gives no clue.
• killall QuickLookUIService (SIGTERM) does not clear it — the process survives and keeps the same PID. kill -9 is required.
• This matches the long-standing Apple bug where Quick Look blocks volume ejection ("The disk wasn't ejected because one or more programs may be using it"), which also only clears with kill -9.

Where the bug sits, and what I'm asking for

The leaked presenter is Apple's defect and I'll file that separately with Feedback Assistant. The actionable part for the client is the error handling.

Right now EBUSY from NSFileProviderManager.evictItem is surfaced as a generic "unable to communicate with a helper application", which points the user at the extension being broken. It cost me a long detour through restarting the client, re-registering the File Provider extension, checking auth, and checking pinning state — none of which was relevant.

Suggestions, in order of value:

1. Map EBUSY / NSFileProviderError busy conditions to a distinct message, e.g. "This file is currently in use by another application and cannot be removed. Close any preview or app using it and try again."
2. Optionally name the holding process — it is available via the File Provider APIs and would make this self-service.
3. Consider retrying once after a short delay for genuinely transient busy states, but not silently, since this one never resolves on its own.

Client configuration

• Nextcloud desktop client: 34.0.1
• Operating system: macOS 26.5.1 (build 25F80)
• File Provider framework: 4018.120.24
• Installation: official macOS build
• VFS: enabled (File Provider based)
• Server: Hetzner Storage Share (hosted Nextcloud)

Related

• [Bug]: MacOS Client with VFS: Sometimes files are not evicted randomly #7832 — "MacOS Client with VFS: Sometimes files are not evicted randomly" (closed) — likely the same root cause, reported without a reproduction
• "Remove download" option missing randomly for materialised files/folders in v34.0.0 #10517, macOS File Provider: “Remove Downloaded Items” only partially evicts folders and is missing for some downloaded files #10555, "Remove Download" unavailable on folders #10085, [Bug]: Macos - Can't evict more than 10 files (or items) in a row. #9757 — adjacent eviction/context-menu issues, different triggers
• [Bug]: Couldn't communicate with a helper application #9432 — "Couldn't communicate with a helper application" (open) — same generic error text surfacing for an apparently different trigger (a folder stuck desynced); no repro steps given. Cited here as evidence that this error string is overloaded across multiple root causes, reinforcing the ask below to make it more specific.

[pixelastronauts]

Workaround: auto-clearing watcher (confirmed working)

Edit: the version originally posted here checked for the leak proactively (before ever clicking "Remove download"), using either fileproviderctl dump or window state as a heuristic. Both turned out broken under real conditions and have been replaced below — leaving the original write-up would have sent people down a path that doesn't actually work, so here's what I learned and what actually holds up:

• fileproviderctl dump silently returns a redacted, presenter-free result for callers that don't hold Full Disk Access. A plain background LaunchAgent doesn't have it, so a watcher built on that command was effectively blind to the very thing it was supposed to detect — it looked fine when tested from an already-privileged interactive terminal, but did nothing once actually running in the background.
• A window-state heuristic (CGWindowList / kCGWindowIsOnscreen, trying to tell an active preview apart from the leaked one) turned out unreliable in the other direction: it also fired while a preview was genuinely still open, killing it mid-view. kCGWindowIsOnscreen is not a trustworthy signal for this particular window.

Replaced with a reactive design: it only acts on a confirmed real failure, by watching the unified log for fileproviderd's own "Eviction ... POSIX 16" error, and clears QuickLookUIService/quicklookd the moment that happens. Trade-off: the first "Remove download" click after closing a preview still shows the error once; the retry right after succeeds, since the presenter's been cleared in the second between clicks. It never touches Quick Look while a preview is actually open, since it only reacts to a real eviction failure, not a guess.

Runs as a LaunchAgent, ~0 CPU at idle.

nc-evict-autofix.sh

#!/usr/bin/env bash
set -uo pipefail

LOGFILE="$HOME/Library/Logs/nc-evict-autofix.log"
mkdir -p "$(dirname "$LOGFILE")"

echo "$(date '+%Y-%m-%d %H:%M:%S')  watcher started (pid $$)" >> "$LOGFILE"

log stream --style compact --predicate \
  'process == "fileproviderd" AND eventMessage CONTAINS[c] "Eviction" AND eventMessage CONTAINS[c] "POSIX 16"' \
  2>>"$LOGFILE" \
  | while IFS= read -r line; do
      # `log stream` prints a one-line "Filtering the log data using ..."
      # preamble to stdout before it starts forwarding matches. That line
      # echoes the predicate text back, so it ALSO contains the words
      # "Eviction" and "POSIX 16" as substrings -- a naive content check
      # matches it too. Guard against that explicitly, and additionally
      # require the line to start with a real timestamp (how every
      # genuine --style compact log entry begins), so only an actual
      # matching log record can ever trigger the kill.
      case "$line" in
        "Filtering the log data using"*)
          continue
          ;;
      esac
      case "$line" in
        [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]\ *)
          ts="$(date '+%Y-%m-%d %H:%M:%S')"
          echo "$ts  confirmed eviction failure (POSIX 16) -> clearing QuickLookUIService/quicklookd" >> "$LOGFILE"
          pkill -9 -x QuickLookUIService 2>/dev/null
          pkill -9 -x quicklookd 2>/dev/null
          ;;
      esac
    done

echo "$(date '+%Y-%m-%d %H:%M:%S')  watcher exited (log stream ended)" >> "$LOGFILE"

LaunchAgent plist (~/Library/LaunchAgents/<label>.plist) + install commands

<?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.example.nc-evict-autofix</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/YOURUSER/Library/Application Support/nc-evict-autofix/nc-evict-autofix.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <dict>
        <key>SuccessfulExit</key>
        <false/>
    </dict>
    <key>ProcessType</key>
    <string>Background</string>
    <key>LowPriorityIO</key>
    <true/>
    <key>Nice</key>
    <integer>10</integer>
</dict>
</plist>

launchctl bootstrap "gui/$(id -u)" ~/Library/LaunchAgents/com.example.nc-evict-autofix.plist
launchctl enable "gui/$(id -u)/com.example.nc-evict-autofix"

Obviously this belongs in the client itself, not in everyone's ~/Library/LaunchAgents — but the "only trust a confirmed failure from fileproviderd's own log, don't guess from window/process state" lesson might be a useful building block for suggestion #3 above (safe, targeted retry instead of a blind delayed one).