[Bug]: macOS File Provider batch upload writes 0 bytes and triggers mass folder rename

Bug description

When batch-uploading a folder of large microscopy images (~98–220 PNG files, each 17–19 MB, totalling 1.6–2.9 GB) into Nextcloud via the macOS File Provider (Virtual Files), two critical issues occur simultaneously:

1. 
   

   Silent upload failure (0-byte writes): The server receives PUT requests with the correct Content-Length header, but 0 bytes of actual data are written. The client shows sync as "completed" within seconds (far too fast for ~4.5 GB) and marks files with a cloud-with-exclamation-mark icon — but provides no error notification or alert. The user must manually inspect individual files to discover the failure.

   
   


2. 
   

   Mass folder rename: All top-level folders in the user's file tree (including unrelated ones and hidden internal directories like .lock, .resource, .sync) are renamed by appending " 2" to their names. The renamed folders contain the original data; empty 0 KB ghost folders are created with the original names. All 12 renames occurred within the same second (12:48:59–12:49:00 UTC), suggesting a single event rather than individual conflicts.

   
   

Steps to reproduce

1. Use Nextcloud Desktop Client 33.0.5 on macOS with Virtual Files (File Provider) enabled


2. Copy a folder containing ~100+ large PNG files (17–19 MB each, ~1.6 GB total) into the Nextcloud virtual directory in Finder


3. Wait for sync to "complete" (it finishes suspiciously fast)


4. Check the files in the Nextcloud web UI — they are either missing or 0 bytes


5. Check all top-level folders — they have been renamed with " 2" suffix

Expected behavior

• Files should be fully uploaded with correct sizes


• Upload failures should be clearly reported to the user via notification


• Unrelated folders should not be renamed

Actual behavior

• Server receives 0 bytes for each file despite correct Content-Length headers


• Client reports sync as complete with no error notification


• All top-level folders (including unrelated ones and hidden directories) are mass-renamed with " 2" suffix within the same second

Server error log (representative entry, repeated for every file)

{

  "level": 3,

  "time": "2026-06-23T13:37:52+00:00",

  "remoteAddr": "<redacted>",

  "user": "<user>",

  "method": "PUT",

  "url": "/remote.php/dav/files/<user>/<redacted-path>/0041.png",

  "message": "Expected file size of 19313119 bytes, but actually read from Nextcloud client and written to Nextcloud storage was 0 bytes. Possibly a network issue on the sender side, or an error when the server was writing to the storage device."

}

Server-side activity log (folder renames, all within 1 second)

All 12 top-level folders were renamed within the same second, including unrelated folders and hidden internal directories:

+---------------------+--------------+------------------+

| ts                  | subject      | file             |

+---------------------+--------------+------------------+

| 2026-06-23 12:49:00 | renamed_self | //<folder_A> 2   |

| 2026-06-23 12:49:00 | renamed_self | //<folder_B> 2   |

| 2026-06-23 12:49:00 | renamed_self | //<folder_C> 2   |

| 2026-06-23 12:49:00 | renamed_self | //Joplin 2       |

| 2026-06-23 12:48:59 | renamed_self | //.lock 2        |

| 2026-06-23 12:48:59 | renamed_self | //.resource 2    |

| 2026-06-23 12:48:59 | renamed_self | //<folder_D> 2   |

| 2026-06-23 12:48:59 | renamed_self | //.sync 2        |

| 2026-06-23 12:48:59 | renamed_self | //<folder_E> 2   |

| 2026-06-23 12:48:59 | renamed_self | //<folder_F> 2   |

| 2026-06-23 12:48:59 | renamed_self | //zotero 2       |

| 2026-06-23 12:48:59 | renamed_self | //Photos 2       |

+---------------------+--------------+------------------+

Files being uploaded

• Folder 1: 98 PNG files, 1.6 GB total (microscopy images, ~17–19 MB each)


• Folder 2: 220 files, 2.9 GB total (mixed microscopy images and analysis outputs)


• File naming: numeric sequential (0001.png, 0002.png, etc.)

Environment

Component | Version
-- | --
macOS | 26.2 (Build 25C56)
Hardware | MacBook Air M4
Desktop Client | 33.0.5 (Cocoa / File Provider)
Nextcloud Server | 32.0.11 (Docker, nextcloud:32-apache)
Database | MariaDB 11.4
Reverse Proxy | Caddy 2-alpine (HTTPS via Tailscale)
PHP upload limit | 20G
PHP memory limit | 512M

Which files are affected by this bug

All files in the batch upload (PNG images). Additionally, all top-level folders are affected by the rename side effect.

Operating system

macOS

Which version of the operating system you are running

macOS 26.2 (Build 25C56)

Package

Official DMG

Nextcloud Server version

32.0.11

Nextcloud Desktop Client version

33.0.5

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

Present since initial setup with File Provider / Virtual Files

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• [x] Default internal user-backend

Related issues

• #9883 — macOS VFS upload fails for large files (same 0-byte symptom, but only for files >100 MB; this report shows it affects ~18 MB files during batch upload)


• #8694 — macOS VFS severe sync problems (files shown with size 0 bytes)


• Community thread: Thousands of Files Renamed by Mac Clientd — identical folder rename behavior on macOS, developer @iva.horn confirmed investigating

Additional info

The web UI upload works correctly for the same files — this issue is specific to the File Provider / Virtual Files upload path. The 0-byte write and mass folder rename appear to be triggered by the same batch upload event.

## Bug description

When batch-uploading a folder of large microscopy images (~98–220 PNG files, each 17–19 MB, totalling 1.6–2.9 GB) into Nextcloud via the macOS File Provider (Virtual Files), two critical issues occur simultaneously:

1. **Silent upload failure (0-byte writes):** The server receives PUT requests with the correct `Content-Length` header, but 0 bytes of actual data are written. The client shows sync as "completed" within seconds (far too fast for ~4.5 GB) and marks files with a cloud-with-exclamation-mark icon — but provides no error notification or alert. The user must manually inspect individual files to discover the failure.

2. **Mass folder rename:** All top-level folders in the user's file tree (including unrelated ones and hidden internal directories like `.lock`, `.resource`, `.sync`) are renamed by appending " 2" to their names. The renamed folders contain the original data; empty 0 KB ghost folders are created with the original names. All 12 renames occurred within the same second (12:48:59–12:49:00 UTC), suggesting a single event rather than individual conflicts.

## Steps to reproduce

1. Use Nextcloud Desktop Client 33.0.5 on macOS with Virtual Files (File Provider) enabled
2. Copy a folder containing ~100+ large PNG files (17–19 MB each, ~1.6 GB total) into the Nextcloud virtual directory in Finder
3. Wait for sync to "complete" (it finishes suspiciously fast)
4. Check the files in the Nextcloud web UI — they are either missing or 0 bytes
5. Check all top-level folders — they have been renamed with " 2" suffix

## Expected behavior

- Files should be fully uploaded with correct sizes
- Upload failures should be clearly reported to the user via notification
- Unrelated folders should not be renamed

## Actual behavior

- Server receives 0 bytes for each file despite correct Content-Length headers
- Client reports sync as complete with no error notification
- All top-level folders (including unrelated ones and hidden directories) are mass-renamed with " 2" suffix within the same second

## Server error log (representative entry, repeated for every file)

```json
{
"level": 3,
"time": "2026-06-23T13:37:52+00:00",
"remoteAddr": "",
"user": "",
"method": "PUT",
"url": "/remote.php/dav/files///0041.png",
"message": "Expected file size of 19313119 bytes, but actually read from Nextcloud client and written to Nextcloud storage was 0 bytes. Possibly a network issue on the sender side, or an error when the server was writing to the storage device."
}
```

## Server-side activity log (folder renames, all within 1 second)

All 12 top-level folders were renamed within the same second, including unrelated folders and hidden internal directories:

```
+---------------------+--------------+------------------+
| ts | subject | file |
+---------------------+--------------+------------------+
| 2026-06-23 12:49:00 | renamed_self | // 2 |
| 2026-06-23 12:49:00 | renamed_self | // 2 |
| 2026-06-23 12:49:00 | renamed_self | // 2 |
| 2026-06-23 12:49:00 | renamed_self | //Joplin 2 |
| 2026-06-23 12:48:59 | renamed_self | //.lock 2 |
| 2026-06-23 12:48:59 | renamed_self | //.resource 2 |
| 2026-06-23 12:48:59 | renamed_self | // 2 |
| 2026-06-23 12:48:59 | renamed_self | //.sync 2 |
| 2026-06-23 12:48:59 | renamed_self | // 2 |
| 2026-06-23 12:48:59 | renamed_self | // 2 |
| 2026-06-23 12:48:59 | renamed_self | //zotero 2 |
| 2026-06-23 12:48:59 | renamed_self | //Photos 2 |
+---------------------+--------------+------------------+
```

## Files being uploaded

- **Folder 1:** 98 PNG files, 1.6 GB total (microscopy images, ~17–19 MB each)
- **Folder 2:** 220 files, 2.9 GB total (mixed microscopy images and analysis outputs)
- File naming: numeric sequential (0001.png, 0002.png, etc.)

## Environment

| Component | Version |
|---|---|
| macOS | 26.2 (Build 25C56) |
| Hardware | MacBook Air M4 |
| Desktop Client | 33.0.5 (Cocoa / File Provider) |
| Nextcloud Server | 32.0.11 (Docker, `nextcloud:32-apache`) |
| Database | MariaDB 11.4 |
| Reverse Proxy | Caddy 2-alpine (HTTPS via Tailscale) |
| PHP upload limit | 20G |
| PHP memory limit | 512M |

## Which files are affected by this bug

All files in the batch upload (PNG images). Additionally, all top-level folders are affected by the rename side effect.

## Operating system

macOS

## Which version of the operating system you are running

macOS 26.2 (Build 25C56)

## Package

Official DMG

## Nextcloud Server version

32.0.11

## Nextcloud Desktop Client version

33.0.5

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

Present since initial setup with File Provider / Virtual Files

## Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

## Are you using an external user-backend?

- [x] Default internal user-backend

## Related issues

- #9883 — macOS VFS upload fails for large files (same 0-byte symptom, but only for files >100 MB; this report shows it affects ~18 MB files during batch upload)
- #8694 — macOS VFS severe sync problems (files shown with size 0 bytes)
- Community thread: [[Thousands of Files Renamed by Mac Clientd](https://help.nextcloud.com/t/thousands-of-files-renamed-by-mac-clientd/243840)](https://help.nextcloud.com/t/thousands-of-files-renamed-by-mac-clientd/243840) — identical folder rename behavior on macOS, developer @iva.horn confirmed investigating

## Additional info

The web UI upload works correctly for the same files — this issue is specific to the File Provider / Virtual Files upload path. The 0-byte write and mass folder rename appear to be triggered by the same batch upload event.

Start at the macOS File Provider/Virtual Files upload path and reproduce the batch upload using the reported client and server versions. Compare the PUT Content-Length with bytes written and inspect the client events around the simultaneous folder renames; done means files upload fully, failures notify the user, and unrelated folders remain unchanged.

Written by the indexing model from the issue text.