[Bug]: "Edit Locally" fails with permission denied on macOS 26 Tahoe (com.apple.macl sandbox ACL) + main-thread crash in qHash

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

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I've searched it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

## Summary

Clicking **"Edit Locally"** (Korean UI: 로컬에서 열기) in the Nextcloud web UI for a synced file produces a macOS error dialog:

> "Nextcloud" 응용 프로그램에서 "<filename>.xlsx"을(를) 열 수 있는 권한이 없습니다.
> ("Nextcloud" does not have permission to open "<filename>.xlsx")

The target app (Excel in this case) is never launched. Opening the exact same file by double-clicking it in Finder works fine.

## Steps to reproduce

1. Install Nextcloud Desktop 33.0.2 on macOS 26.4.1 (Tahoe), Apple Silicon.
2. Log in to a Nextcloud server using the macOS native File Provider (files under `~/Library/CloudStorage/Nextcloud-<account>/`).
3. Wait for files to sync.
4. In the web UI, open a file's context menu and click **"Edit Locally"**.
5. Browser asks to open Nextcloud via `nc://` URL — approve.

## Expected

The file opens in its associated local app (Excel for `.xlsx`) and edits propagate back via sync.

## Actual

macOS permission-denied dialog shown above. Target app never launched.

## Root-cause diagnosis

### 1. Full Disk Access is already granted to Nextcloud.app

System Settings → Privacy & Security → Full Disk Access: `Nextcloud.app` = ON. So this is **not** a missing TCC grant at the Full Disk Access level.

### 2. Files carry a `com.apple.macl` extended attribute that does not include the Nextcloud main app's sandbox UUID

```
$ xattr -l "~/Library/CloudStorage/Nextcloud-admin@.../<file>.xlsx"
com.apple.lastuseddate#PS: ...
com.apple.macl: <72-byte ACL blob>
com.apple.provenance: ...
```

`com.apple.macl` is the Sandbox Access Control List macOS uses to grant persistent per-file access to sandboxed apps. The ACL was populated by whichever sandboxed app previously touched the file (likely the File Provider Extension, or the app that originally produced the file), but Nextcloud's main app UUID is not on the list. When the main Nextcloud process attempts to hand the file off (via `-[NSWorkspace openURL:]` / `open(2)` / launch-services), the kernel denies it.

- Finder double-click on the same file → opens in Excel without error (Finder is not sandboxed).
- Running `open -a 'Microsoft Excel' <path>` from an admin shell → opens in Excel without error.
- `xattr -d com.apple.macl <file>` without `sudo` silently fails; even `sudo xattr -d` isn't a permanent fix because macOS re-adds `macl` on next sync/touch.

So the denial happens specifically on the handoff path inside the main Nextcloud process; the kernel is blocking because the main app's sandbox UUID isn't in the file's `macl`.

### 3. Separate but possibly related: main-thread crash on `EXC_BAD_ACCESS` in `qHash(QStringView, ...)`

On the first reproduction attempt the app crashed instead of showing the denial dialog. Crash report `Nextcloud-2026-04-14-095004.ips`:

```
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000075a400000
Termination:     Bus error: 10

Faulting thread (com.apple.main-thread):
  0  QtCore            qHash(QStringView, unsigned long) + 68
  1  Nextcloud         + 777092
  2  QtCore            + 964144
  3  libdispatch       _dispatch_call_block_and_release + 32
  4  libdispatch       _dispatch_client_callout + 16
  5  libdispatch       _dispatch_main_queue_drain.cold.6 + 832
  ...
  N  Nextcloud         main + 2832

Target VM: commpage (reserved) 75a400000-a58000000   12.0 GB   --- / ---
```

Bus error reading from a reserved (unmapped) VM region inside `qHash(QStringView, unsigned long)`, called from a `dispatch_async` block on the main queue. Consistent with a `QStringView` pointing at a deallocated buffer — a block captured a view into a short-lived `QString` and ran after the string was destroyed.

Full `.ips` available on request.

## Environment

- **Nextcloud Desktop**: 33.0.2 (build 33.0.2.0)
- **Server**: Nextcloud Hub 8 — 29.0.16 (self-hosted, Docker)
- **OS**: macOS 26.4.1 Tahoe (build 25E253)
- **Architecture**: Apple Silicon (arm64, Mac14,6)
- **Sync mode**: macOS native File Provider (`~/Library/CloudStorage/Nextcloud-<account>/`)
- **Full Disk Access for Nextcloud.app**: granted

## Suggested investigation

- Handoff path for `nc://open/...` URLs: if the main process uses `open(2)` on the POSIX path, the main Nextcloud process's sandbox is checked against the file's `com.apple.macl`. Full Disk Access does **not** appear to cover File Provider paths under `~/Library/CloudStorage/` for this check. Delegating the open to the File Provider Extension (which presumably is in the file's `macl`) may be the right fix.
- Crash in `qHash(QStringView, ...)`: audit any `QtConcurrent::run` / `QMetaObject::invokeMethod` / `dispatch_async` site on the Edit-Locally path that captures a `QStringView` (or raw `QChar*`) instead of owning a `QString` copy.

## Related issues

- #9725 — macOS App Sandbox breaks QtWebEngine used for SSO (open): different symptom, same underlying theme of macOS App Sandbox restrictions on Nextcloud main process.
- #9814 — macOS: Adobe Illustrator freezes when saving `.ai` to Nextcloud desktop location (closed, 33.0.3): resolved sandbox/File-Provider interaction; the fix there may be relevant.

## Workaround

Don't use "Edit Locally". Open files directly from Finder's sidebar → Nextcloud sync folder → double-click. The File Provider serves the file to Finder with correct ACLs, the default app launches normally, and edits propagate back through sync.

### Steps to reproduce

1. Install Nextcloud Desktop 33.0.2 on macOS 26.4.1 (Tahoe), Apple Silicon.
2. Log in to a Nextcloud server (tested with Hub 8 / 29.0.16) using the macOS native File Provider. Sync folder appears under `~/Library/CloudStorage/Nextcloud-<account>/`.
3. Wait for files to sync and confirm "모두 동기화되었습니다! / All files in sync".
4. In the Nextcloud Web UI, right-click any file (e.g. a `.xlsx`) and choose **"Edit Locally"** (로컬에서 열기).
5. Browser prompts to open Nextcloud via the `nc://` URL scheme. Approve.
6. The Nextcloud Desktop app receives the handoff and attempts to open the local copy in the default app (Microsoft Excel).

Result: a macOS dialog appears saying "Nextcloud" 응용 프로그램에서 "<filename>.xlsx"을(를) 열 수 있는 권한이 없습니다. ("Nextcloud" does not have permission to open the file). The target app (Excel) is never launched with the file.

Additional repro note: On some invocations the desktop app crashes instead of showing the permission dialog — crash report `Nextcloud-2026-04-14-095004.ips` shows `EXC_BAD_ACCESS (SIGBUS) / KERN_PROTECTION_FAILURE` in `qHash(QStringView, unsigned long)` on the main thread, dispatched from `_dispatch_call_block_and_release`. Details in the main description above.

### Expected behavior

Clicking "Edit Locally" in the Nextcloud Web UI should:

1. Hand off the `nc://open/...` URL to the Nextcloud Desktop app.
2. Have the Desktop app resolve the path under `~/Library/CloudStorage/Nextcloud-<account>/...` and open it in the default macOS application for that file type (e.g. Microsoft Excel for `.xlsx`).
3. Allow the user to edit the file, with changes propagating back to the server via the File Provider sync.

No permission dialog should appear, and the app should not crash.

Current behavior: the handoff is denied by the macOS sandbox because the file carries a `com.apple.macl` ACL that does not include the Nextcloud main-app sandbox UUID, and on some invocations the app crashes in `qHash(QStringView, unsigned long)` before it can even reach the open call. Opening the exact same file via Finder (double-click) works correctly, confirming that the file itself is fine — only the sandboxed Nextcloud → target-app handoff path is broken.

### Which files are affected by this bug

All files synced via the macOS native File Provider (under `~/Library/CloudStorage/Nextcloud-<account>/`). Reliably reproduced with `.xlsx` files but not specific to file type — the permission denial is triggered by the sandbox ACL (`com.apple.macl`) rather than by file contents. Example path observed: `~/Library/CloudStorage/Nextcloud-admin@nc.ocean-it.kr/통계항목 목록20260410134148.xlsx`.

### Operating system

macOS

### Which version of the operating system you are running.

macOS 26.4.1 Tahoe (build 25E253), Apple Silicon arm64 (Mac14,6)

### Package

Official macOS Virtual files 12+ universal pkg

### Nextcloud Server version

Nextcloud Hub 8 — 29.0.16 (self-hosted, Docker)

### Nextcloud Desktop Client version

33.0.2 (build 33.0.2.0), latest stable

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

Fresh desktop client install

### Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

### Are you using an external user-backend?

- [x] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell

```

### Additional info

_No response_

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Bug]: "Edit Locally" fails with permission denied on macOS 26 Tahoe (com.apple.macl sandbox ACL) + main-thread crash in qHash #9835

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

Bug description

Summary

Steps to reproduce

Expected

Actual

Root-cause diagnosis

1. Full Disk Access is already granted to Nextcloud.app

2. Files carry a `com.apple.macl` extended attribute that does not include the Nextcloud main app's sandbox UUID

3. Separate but possibly related: main-thread crash on `EXC_BAD_ACCESS` in `qHash(QStringView, ...)`

Environment

Suggested investigation

Related issues

Workaround

Steps to reproduce

Expected behavior

Which files are affected by this bug

Operating system

Which version of the operating system you are running.

Package

Nextcloud Server version

Nextcloud Desktop Client version

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

Are you using the Nextcloud Server Encryption module?

Are you using an external user-backend?

Nextcloud Server logs

Additional info

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

[Bug]: "Edit Locally" fails with permission denied on macOS 26 Tahoe (com.apple.macl sandbox ACL) + main-thread crash in qHash #9835

Description

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

Bug description

Summary

Steps to reproduce

Expected

Actual

Root-cause diagnosis

1. Full Disk Access is already granted to Nextcloud.app

2. Files carry a com.apple.macl extended attribute that does not include the Nextcloud main app's sandbox UUID

3. Separate but possibly related: main-thread crash on EXC_BAD_ACCESS in qHash(QStringView, ...)

Environment

Suggested investigation

Related issues

Workaround

Steps to reproduce

Expected behavior

Which files are affected by this bug

Operating system

Which version of the operating system you are running.

Package

Nextcloud Server version

Nextcloud Desktop Client version

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

Are you using the Nextcloud Server Encryption module?

Are you using an external user-backend?

Nextcloud Server logs

Additional info

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

2. Files carry a `com.apple.macl` extended attribute that does not include the Nextcloud main app's sandbox UUID

3. Separate but possibly related: main-thread crash on `EXC_BAD_ACCESS` in `qHash(QStringView, ...)`