Client repeatedly MKCOLs External Storage roots (405)

### ⚠️ 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 have searched for 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

## ⚠️ Which version of the Nextcloud Desktop Client are you using?

`mirall/33.0.4` (latest stable, published 2026-05-04)

## What operating system is your client running on?

macOS (verified on macOS 26.4.1, Build 25E253, Apple Silicon)

## What server are you using?

Nextcloud server 33.0.2.2 (in Docker, official `nextcloud:33` image). Behavior is independent of server version — the 405 response is correct per WebDAV RFC 4918 §9.3.

## Affected feature

macOS Virtual Files (File Provider Extension) + External Storage mounts (type **Local**).

---

## Describe the bug

When Nextcloud Desktop Client (mirall) on macOS has Virtual Files enabled and the user's account contains one or more **External Storage** mounts (e.g. a `Local` storage type pointing to `/mnt/`), the desktop client periodically attempts to **create** those mount roots remotely via WebDAV `MKCOL`. The server correctly rejects each attempt with `405 Method Not Allowed` ("The resource you tried to create already exists") because External Storage roots exist server-side as virtual folders.

The client logs the failure:

```
[Item][error] Could not create new folder at:
https:///remote.php/dav/files//
received error: 405
The resource you tried to create already exists
```

This by itself appears harmless, but it is correlated with — and we believe causes — a **persistent enumeration failure** in the macOS FileProvider framework: items that should be top-level children of those External Storage roots remain unreachable from Finder, returning generic "you don't have permission to see its contents" or showing partial (wrong) child counts.

`fileproviderctl evaluate` confirms the items get latched with contradictory state (`isDownloaded=1` AND `isDownloading=1`, `isUploading=1` with `uploadingError=NSFileProviderErrorDomain Code=-2005`) that never clears.

The Apple `NSFileProviderItemIdentifier`s queried by macOS but not found by the NC FP extension correspond exactly to:
- The External Storage roots themselves (NC `oc_filecache.fileid` of each mount root)
- Their immediate top-level child folders

i.e. **the client's local Realm DB never registers External Storage roots or their top-level children**, but macOS's FileProvider framework remembers them from some prior state (working set discovery) and queries the FP extension for them repeatedly.

## Steps to reproduce

1. On a Nextcloud server, configure External Storage of type **Local** (or any backend) mounted at the top of a user's namespace, e.g. `/MyExtMount` → `/mnt/some/host/path`. Add some folders inside the mount.
2. On macOS, install Nextcloud Desktop Client and enable Virtual Files / File Provider integration.
3. Sign in with the user account that has access to `/MyExtMount`.
4. Wait ~30 min to a few hours.

## Expected result

- `/MyExtMount` appears as a normal folder in Finder under the Nextcloud FileProvider mount.
- Children of `/MyExtMount` enumerate correctly on demand.
- No `MKCOL` attempts on `/MyExtMount` (it already exists per the PROPFIND of the parent).

## Actual result

- Periodic `MKCOL /dav/files//MyExtMount` requests, every ~2-4 h.
- Each returns `405 Method Not Allowed` ("resource already exists").
- Each is logged as `Could not create new folder` at the Item level by the FP extension.
- macOS FP framework subsequently queries `NSFileProviderItemIdentifier`s for the mount root + top-level children that the FP extension cannot resolve.
- Finder access to subfolders below the mount root fails or shows partial/wrong enumeration.
- State **does not self-heal** across:
- NC.app restart
- Killing + relaunching FileProviderExt
- Renaming/deleting the FP domain group container (`~/Library/Group Containers/NKUJUXUJ3B.com.nextcloud.desktopclient/File Provider Domains//`), because macOS preserves item identifiers across same-UUID domain rebuilds.
- `fileproviderctl repair -a ` (fails with `FPCKDomain Code=65`).
- The only known workaround that clears the corrupted state is **Disconnect → Sign back in** in the NC Desktop GUI, which forces a new account UUID and therefore a new FP domain UUID — but the underlying bug then re-accumulates over hours.

## Server logs (relevant excerpts)

```
{"time":"2026-05-13T02:25:48+00:00","method":"MKCOL",
"url":"/nextcloud/remote.php/dav/files/chris/A",
"userAgent":"Mozilla/5.0 (Macintosh) mirall/33.0.4 (Nextcloud, …)",
"exception":{"Exception":"Sabre\\DAV\\Exception\\MethodNotAllowed",
"Message":"The resource you tried to create already exists"}}
```

Repeats 11 times over 24 h (most pairs are the same reqId logged twice; one pair is a fast retry +2 s with a different reqId).

## Client logs (relevant excerpts from `/Logs/*.jsonl`)

```
[Enumerator][info] Set up enumerator. url: https:///dav/files/
[Enumerator][info] No remote changes found in materialized items.
[Item ][error] Could not create new folder at:
https:///dav/files//A
received error: 405
The resource you tried to create already exists
[Enumerator][error] Could not find item with identifier.
(item: 00047556oc32b3i7gvmr)
[Enumerator][error] Could not find item with identifier.
(item: 00158151oc32b3i7gvmr)
```

24 h count: 24 `Could not create new folder` (~12 unique MKCOL attempts × 2 log lines each), 39 `Could not find item with identifier` (4 distinct item IDs, mapping exactly to External Storage roots + top-level children per NC's filecache).

## Server `oc_filecache` cross-reference

Querying NC server's database confirms the "missing" item IDs the client cannot resolve are real `fileid` entries belonging to External Storage mount roots and their top-level children:

```sql
mysql> SELECT fileid, storage, path, name FROM oc_filecache
WHERE fileid IN (47556, 158151, 158284, 252828);
+--------+---------+-------------------------+-------------------------+
| fileid | storage | path | name |
+--------+---------+-------------------------+-------------------------+
| 47556 | 4 | | | ← "A" ext-storage root
| 158151 | 6 | | | ← "B" ext-storage root
| 158284 | 6 | 200_X | 200_X |
| 252828 | 6 | Contact_Weekly_Reports | Contact_Weekly_Reports |
+--------+---------+-------------------------+-------------------------+

mysql> SELECT numeric_id, id FROM oc_storages
WHERE numeric_id IN (4, 6);
+------------+---------------------------+
| numeric_id | id |
+------------+---------------------------+
| 4 | local::/mnt/A/ |
| 6 | local::/mnt/B/ |
+------------+---------------------------+
```

The client *can* enumerate these via PROPFIND (we see them in Finder for a short window after fresh setup), but the FP extension does not appear to record them as `NSFileProviderItem`s in the local Realm DB.

## Suggested investigation directions for the maintainers

1. In the sync/discovery code path — likely `src/libsync/discoveryphase.cpp` and the propagator — verify that items with the `RemotePermissions::IsMounted` flag (`M` permission, indicating External Storage mount root) are correctly inserted into the client's Realm DB / `NSFileProviderItem` registry, not just enumerated.
2. Audit the path that emits `MKCOL` for any folder. Pre-flight check: does the parent's PROPFIND already include this child as a ``? If yes, **never emit `MKCOL`** — instead, materialize the existing item into the local registry.
3. Even if `MKCOL` fires and gets 405, the client should interpret 405 on a ``-confirmed existing path as **success** ("collection already exists"), perform a PROPFIND on the path, and register the resulting properties as a fresh `NSFileProviderItem`. Currently this code path appears to abort and log the 405 as an error without ever registering the item.
4. Specific to macOS: the FP framework's persistence of item identifiers across same-UUID domain rebuilds means that any client-side fix must also include a **migration path** for users currently stuck — clearing the FP framework's item cache requires either a new account UUID (full disconnect/reconnect) or an Apple-private mechanism we have not identified.

## Similar but distinct issues

Searched #1058, #4269, #4636, #7194, #8576, #8599, #9029, #9138, #9279, #11728, #17064 (server-side), #18637 (server-side), #19216 (server-side), #20236 (server-side), #53312 (server-side). None describes the exact MKCOL-on-existing-External-Storage-root pattern producing FP-framework item-ID orphans on macOS. The closest is #8576 (Windows endless re-sync of SMB external storage) which may share an underlying External Storage handling defect but presents differently (no MKCOL spec'd, Windows VFS).

## Environment

- Client: `mirall/33.0.4` (verified User-Agent)
- macOS: 26.4.1 (Build 25E253), Apple Silicon
- Server: Nextcloud 33.0.2.2, Docker (`nextcloud:33` image), MariaDB 11
- External Storage: `Local` backend, 2 mounts (`A` ~111 GB / 70k files, `B` ~13 GB / ~5k files)
- Network: Tailscale (not LAN-direct), but issue reproduces on LAN-direct (192.168.x.x) too

## Operator workaround in use

We have replaced the macOS FileProvider mount with a direct SMB mount over Tailscale for the affected External Storage paths. SMB does not exhibit this bug (it has no equivalent of the FP item-ID registry; it's a real network filesystem). This issue does not affect web UI, iOS clients, or non-FileProvider sync clients.

### Steps to reproduce

## ⚠️ Which version of the Nextcloud Desktop Client are you using?

`mirall/33.0.4` (latest stable, published 2026-05-04)

## What operating system is your client running on?

macOS (verified on macOS 26.4.1, Build 25E253, Apple Silicon)

## What server are you using?

Nextcloud server 33.0.2.2 (in Docker, official `nextcloud:33` image). Behavior is independent of server version — the 405 response is correct per WebDAV RFC 4918 §9.3.

## Affected feature

macOS Virtual Files (File Provider Extension) + External Storage mounts (type **Local**).

---

## Describe the bug

When Nextcloud Desktop Client (mirall) on macOS has Virtual Files enabled and the user's account contains one or more **External Storage** mounts (e.g. a `Local` storage type pointing to `/mnt/`), the desktop client periodically attempts to **create** those mount roots remotely via WebDAV `MKCOL`. The server correctly rejects each attempt with `405 Method Not Allowed` ("The resource you tried to create already exists") because External Storage roots exist server-side as virtual folders.

The client logs the failure:

```
[Item][error] Could not create new folder at:
https:///remote.php/dav/files//
received error: 405
The resource you tried to create already exists
```

This by itself appears harmless, but it is correlated with — and we believe causes — a **persistent enumeration failure** in the macOS FileProvider framework: items that should be top-level children of those External Storage roots remain unreachable from Finder, returning generic "you don't have permission to see its contents" or showing partial (wrong) child counts.

`fileproviderctl evaluate` confirms the items get latched with contradictory state (`isDownloaded=1` AND `isDownloading=1`, `isUploading=1` with `uploadingError=NSFileProviderErrorDomain Code=-2005`) that never clears.

The Apple `NSFileProviderItemIdentifier`s queried by macOS but not found by the NC FP extension correspond exactly to:
- The External Storage roots themselves (NC `oc_filecache.fileid` of each mount root)
- Their immediate top-level child folders

i.e. **the client's local Realm DB never registers External Storage roots or their top-level children**, but macOS's FileProvider framework remembers them from some prior state (working set discovery) and queries the FP extension for them repeatedly.

## Steps to reproduce

1. On a Nextcloud server, configure External Storage of type **Local** (or any backend) mounted at the top of a user's namespace, e.g. `/MyExtMount` → `/mnt/some/host/path`. Add some folders inside the mount.
2. On macOS, install Nextcloud Desktop Client and enable Virtual Files / File Provider integration.
3. Sign in with the user account that has access to `/MyExtMount`.
4. Wait ~30 min to a few hours.

## Expected result

- `/MyExtMount` appears as a normal folder in Finder under the Nextcloud FileProvider mount.
- Children of `/MyExtMount` enumerate correctly on demand.
- No `MKCOL` attempts on `/MyExtMount` (it already exists per the PROPFIND of the parent).

## Actual result

- Periodic `MKCOL /dav/files//MyExtMount` requests, every ~2-4 h.
- Each returns `405 Method Not Allowed` ("resource already exists").
- Each is logged as `Could not create new folder` at the Item level by the FP extension.
- macOS FP framework subsequently queries `NSFileProviderItemIdentifier`s for the mount root + top-level children that the FP extension cannot resolve.
- Finder access to subfolders below the mount root fails or shows partial/wrong enumeration.
- State **does not self-heal** across:
- NC.app restart
- Killing + relaunching FileProviderExt
- Renaming/deleting the FP domain group container (`~/Library/Group Containers/NKUJUXUJ3B.com.nextcloud.desktopclient/File Provider Domains//`), because macOS preserves item identifiers across same-UUID domain rebuilds.
- `fileproviderctl repair -a ` (fails with `FPCKDomain Code=65`).
- The only known workaround that clears the corrupted state is **Disconnect → Sign back in** in the NC Desktop GUI, which forces a new account UUID and therefore a new FP domain UUID — but the underlying bug then re-accumulates over hours.

## Server logs (relevant excerpts)

```
{"time":"2026-05-13T02:25:48+00:00","method":"MKCOL",
"url":"/nextcloud/remote.php/dav/files/chris/A",
"userAgent":"Mozilla/5.0 (Macintosh) mirall/33.0.4 (Nextcloud, …)",
"exception":{"Exception":"Sabre\\DAV\\Exception\\MethodNotAllowed",
"Message":"The resource you tried to create already exists"}}
```

Repeats 11 times over 24 h (most pairs are the same reqId logged twice; one pair is a fast retry +2 s with a different reqId).

## Client logs (relevant excerpts from `/Logs/*.jsonl`)

```
[Enumerator][info] Set up enumerator. url: https:///dav/files/
[Enumerator][info] No remote changes found in materialized items.
[Item ][error] Could not create new folder at:
https:///dav/files//A
received error: 405
The resource you tried to create already exists
[Enumerator][error] Could not find item with identifier.
(item: 00047556oc32b3i7gvmr)
[Enumerator][error] Could not find item with identifier.
(item: 00158151oc32b3i7gvmr)
```

24 h count: 24 `Could not create new folder` (~12 unique MKCOL attempts × 2 log lines each), 39 `Could not find item with identifier` (4 distinct item IDs, mapping exactly to External Storage roots + top-level children per NC's filecache).

## Server `oc_filecache` cross-reference

Querying NC server's database confirms the "missing" item IDs the client cannot resolve are real `fileid` entries belonging to External Storage mount roots and their top-level children:

```sql
mysql> SELECT fileid, storage, path, name FROM oc_filecache
WHERE fileid IN (47556, 158151, 158284, 252828);
+--------+---------+-------------------------+-------------------------+
| fileid | storage | path | name |
+--------+---------+-------------------------+-------------------------+
| 47556 | 4 | | | ← "A" ext-storage root
| 158151 | 6 | | | ← "B" ext-storage root
| 158284 | 6 | 200_FP&A | 200_FP&A |
| 252828 | 6 | Contact_Weekly_Reports | Contact_Weekly_Reports |
+--------+---------+-------------------------+-------------------------+

mysql> SELECT numeric_id, id FROM oc_storages
WHERE numeric_id IN (4, 6);
+------------+---------------------------+
| numeric_id | id |
+------------+---------------------------+
| 4 | local::/mnt/A/ |
| 6 | local::/mnt/B/ |
+------------+---------------------------+
```

The client *can* enumerate these via PROPFIND (we see them in Finder for a short window after fresh setup), but the FP extension does not appear to record them as `NSFileProviderItem`s in the local Realm DB.

## Suggested investigation directions for the maintainers

1. In the sync/discovery code path — likely `src/libsync/discoveryphase.cpp` and the propagator — verify that items with the `RemotePermissions::IsMounted` flag (`M` permission, indicating External Storage mount root) are correctly inserted into the client's Realm DB / `NSFileProviderItem` registry, not just enumerated.
2. Audit the path that emits `MKCOL` for any folder. Pre-flight check: does the parent's PROPFIND already include this child as a ``? If yes, **never emit `MKCOL`** — instead, materialize the existing item into the local registry.
3. Even if `MKCOL` fires and gets 405, the client should interpret 405 on a ``-confirmed existing path as **success** ("collection already exists"), perform a PROPFIND on the path, and register the resulting properties as a fresh `NSFileProviderItem`. Currently this code path appears to abort and log the 405 as an error without ever registering the item.
4. Specific to macOS: the FP framework's persistence of item identifiers across same-UUID domain rebuilds means that any client-side fix must also include a **migration path** for users currently stuck — clearing the FP framework's item cache requires either a new account UUID (full disconnect/reconnect) or an Apple-private mechanism we have not identified.

## Similar but distinct issues

Searched #1058, #4269, #4636, #7194, #8576, #8599, #9029, #9138, #9279, #11728, #17064 (server-side), #18637 (server-side), #19216 (server-side), #20236 (server-side), #53312 (server-side). None describes the exact MKCOL-on-existing-External-Storage-root pattern producing FP-framework item-ID orphans on macOS. The closest is #8576 (Windows endless re-sync of SMB external storage) which may share an underlying External Storage handling defect but presents differently (no MKCOL spec'd, Windows VFS).

## Environment

- Client: `mirall/33.0.4` (verified User-Agent)
- macOS: 26.4.1 (Build 25E253), Apple Silicon
- Server: Nextcloud 33.0.2.2, Docker (`nextcloud:33` image), MariaDB 11
- External Storage: `Local` backend, 2 mounts (`A` ~111 GB / 70k files, `B` ~13 GB / ~5k files)
- Network: Tailscale (not LAN-direct), but issue reproduces on LAN-direct (192.168.x.x) too

## Operator workaround in use

We have replaced the macOS FileProvider mount with a direct SMB mount over Tailscale for the affected External Storage paths. SMB does not exhibit this bug (it has no equivalent of the FP item-ID registry; it's a real network filesystem). This issue does not affect web UI, iOS clients, or non-FileProvider sync clients.

### Expected behavior

## ⚠️ Which version of the Nextcloud Desktop Client are you using?

`mirall/33.0.4` (latest stable, published 2026-05-04)

## What operating system is your client running on?

macOS (verified on macOS 26.4.1, Build 25E253, Apple Silicon)

## What server are you using?

Nextcloud server 33.0.2.2 (in Docker, official `nextcloud:33` image). Behavior is independent of server version — the 405 response is correct per WebDAV RFC 4918 §9.3.

## Affected feature

macOS Virtual Files (File Provider Extension) + External Storage mounts (type **Local**).

---

## Describe the bug

When Nextcloud Desktop Client (mirall) on macOS has Virtual Files enabled and the user's account contains one or more **External Storage** mounts (e.g. a `Local` storage type pointing to `/mnt/`), the desktop client periodically attempts to **create** those mount roots remotely via WebDAV `MKCOL`. The server correctly rejects each attempt with `405 Method Not Allowed` ("The resource you tried to create already exists") because External Storage roots exist server-side as virtual folders.

The client logs the failure:

```
[Item][error] Could not create new folder at:
https:///remote.php/dav/files//
received error: 405
The resource you tried to create already exists
```

This by itself appears harmless, but it is correlated with — and we believe causes — a **persistent enumeration failure** in the macOS FileProvider framework: items that should be top-level children of those External Storage roots remain unreachable from Finder, returning generic "you don't have permission to see its contents" or showing partial (wrong) child counts.

`fileproviderctl evaluate` confirms the items get latched with contradictory state (`isDownloaded=1` AND `isDownloading=1`, `isUploading=1` with `uploadingError=NSFileProviderErrorDomain Code=-2005`) that never clears.

The Apple `NSFileProviderItemIdentifier`s queried by macOS but not found by the NC FP extension correspond exactly to:
- The External Storage roots themselves (NC `oc_filecache.fileid` of each mount root)
- Their immediate top-level child folders

i.e. **the client's local Realm DB never registers External Storage roots or their top-level children**, but macOS's FileProvider framework remembers them from some prior state (working set discovery) and queries the FP extension for them repeatedly.

## Steps to reproduce

1. On a Nextcloud server, configure External Storage of type **Local** (or any backend) mounted at the top of a user's namespace, e.g. `/MyExtMount` → `/mnt/some/host/path`. Add some folders inside the mount.
2. On macOS, install Nextcloud Desktop Client and enable Virtual Files / File Provider integration.
3. Sign in with the user account that has access to `/MyExtMount`.
4. Wait ~30 min to a few hours.

## Expected result

- `/MyExtMount` appears as a normal folder in Finder under the Nextcloud FileProvider mount.
- Children of `/MyExtMount` enumerate correctly on demand.
- No `MKCOL` attempts on `/MyExtMount` (it already exists per the PROPFIND of the parent).

## Actual result

- Periodic `MKCOL /dav/files//MyExtMount` requests, every ~2-4 h.
- Each returns `405 Method Not Allowed` ("resource already exists").
- Each is logged as `Could not create new folder` at the Item level by the FP extension.
- macOS FP framework subsequently queries `NSFileProviderItemIdentifier`s for the mount root + top-level children that the FP extension cannot resolve.
- Finder access to subfolders below the mount root fails or shows partial/wrong enumeration.
- State **does not self-heal** across:
- NC.app restart
- Killing + relaunching FileProviderExt
- Renaming/deleting the FP domain group container (`~/Library/Group Containers/NKUJUXUJ3B.com.nextcloud.desktopclient/File Provider Domains//`), because macOS preserves item identifiers across same-UUID domain rebuilds.
- `fileproviderctl repair -a ` (fails with `FPCKDomain Code=65`).
- The only known workaround that clears the corrupted state is **Disconnect → Sign back in** in the NC Desktop GUI, which forces a new account UUID and therefore a new FP domain UUID — but the underlying bug then re-accumulates over hours.

## Server logs (relevant excerpts)

```
{"time":"2026-05-13T02:25:48+00:00","method":"MKCOL",
"url":"/nextcloud/remote.php/dav/files/chris/A",
"userAgent":"Mozilla/5.0 (Macintosh) mirall/33.0.4 (Nextcloud, …)",
"exception":{"Exception":"Sabre\\DAV\\Exception\\MethodNotAllowed",
"Message":"The resource you tried to create already exists"}}
```

Repeats 11 times over 24 h (most pairs are the same reqId logged twice; one pair is a fast retry +2 s with a different reqId).

## Client logs (relevant excerpts from `/Logs/*.jsonl`)

```
[Enumerator][info] Set up enumerator. url: https:///dav/files/
[Enumerator][info] No remote changes found in materialized items.
[Item ][error] Could not create new folder at:
https:///dav/files//A
received error: 405
The resource you tried to create already exists
[Enumerator][error] Could not find item with identifier.
(item: 00047556oc32b3i7gvmr)
[Enumerator][error] Could not find item with identifier.
(item: 00158151oc32b3i7gvmr)
```

24 h count: 24 `Could not create new folder` (~12 unique MKCOL attempts × 2 log lines each), 39 `Could not find item with identifier` (4 distinct item IDs, mapping exactly to External Storage roots + top-level children per NC's filecache).

## Server `oc_filecache` cross-reference

Querying NC server's database confirms the "missing" item IDs the client cannot resolve are real `fileid` entries belonging to External Storage mount roots and their top-level children:

```sql
mysql> SELECT fileid, storage, path, name FROM oc_filecache
WHERE fileid IN (47556, 158151, 158284, 252828);
+--------+---------+-------------------------+-------------------------+
| fileid | storage | path | name |
+--------+---------+-------------------------+-------------------------+
| 47556 | 4 | | | ← "A" ext-storage root
| 158151 | 6 | | | ← "B" ext-storage root
| 158284 | 6 | 200_X | 200_X |
| 252828 | 6 | Contact_Weekly_Reports | Contact_Weekly_Reports |
+--------+---------+-------------------------+-------------------------+

mysql> SELECT numeric_id, id FROM oc_storages
WHERE numeric_id IN (4, 6);
+------------+---------------------------+
| numeric_id | id |
+------------+---------------------------+
| 4 | local::/mnt/A/ |
| 6 | local::/mnt/B/ |
+------------+---------------------------+
```

The client *can* enumerate these via PROPFIND (we see them in Finder for a short window after fresh setup), but the FP extension does not appear to record them as `NSFileProviderItem`s in the local Realm DB.

## Suggested investigation directions for the maintainers

1. In the sync/discovery code path — likely `src/libsync/discoveryphase.cpp` and the propagator — verify that items with the `RemotePermissions::IsMounted` flag (`M` permission, indicating External Storage mount root) are correctly inserted into the client's Realm DB / `NSFileProviderItem` registry, not just enumerated.
2. Audit the path that emits `MKCOL` for any folder. Pre-flight check: does the parent's PROPFIND already include this child as a ``? If yes, **never emit `MKCOL`** — instead, materialize the existing item into the local registry.
3. Even if `MKCOL` fires and gets 405, the client should interpret 405 on a ``-confirmed existing path as **success** ("collection already exists"), perform a PROPFIND on the path, and register the resulting properties as a fresh `NSFileProviderItem`. Currently this code path appears to abort and log the 405 as an error without ever registering the item.
4. Specific to macOS: the FP framework's persistence of item identifiers across same-UUID domain rebuilds means that any client-side fix must also include a **migration path** for users currently stuck — clearing the FP framework's item cache requires either a new account UUID (full disconnect/reconnect) or an Apple-private mechanism we have not identified.

## Similar but distinct issues

Searched #1058, #4269, #4636, #7194, #8576, #8599, #9029, #9138, #9279, #11728, #17064 (server-side), #18637 (server-side), #19216 (server-side), #20236 (server-side), #53312 (server-side). None describes the exact MKCOL-on-existing-External-Storage-root pattern producing FP-framework item-ID orphans on macOS. The closest is #8576 (Windows endless re-sync of SMB external storage) which may share an underlying External Storage handling defect but presents differently (no MKCOL spec'd, Windows VFS).

## Environment

- Client: `mirall/33.0.4` (verified User-Agent)
- macOS: 26.4.1 (Build 25E253), Apple Silicon
- Server: Nextcloud 33.0.2.2, Docker (`nextcloud:33` image), MariaDB 11
- External Storage: `Local` backend, 2 mounts (`A` ~111 GB / 70k files, `B` ~13 GB / ~5k files)
- Network: Tailscale (not LAN-direct), but issue reproduces on LAN-direct (192.168.x.x) too

## Operator workaround in use

We have replaced the macOS FileProvider mount with a direct SMB mount over Tailscale for the affected External Storage paths. SMB does not exhibit this bug (it has no equivalent of the FP item-ID registry; it's a real network filesystem). This issue does not affect web UI, iOS clients, or non-FileProvider sync clients.

### Which files are affected by this bug

All

### Operating system

macOS

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

MacOS 26.4.1

### Installation method

Official Linux AppImage

### Nextcloud Server version

33.0.4

### Nextcloud Desktop Client version

33.0.4

### Did this occur after an update or on a clean installation?

Clean desktop client installation

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

No

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

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

### Nextcloud Server logs

```shell

```

### Additional info

[debug_archive.zip](https://github.com/user-attachments/files/27755343/debug_archive.zip)