[Bug]: macOS Desktop Client with Virtual Files enabled fails to upload files larger than ~100 MB

[Daehnie]

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

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

Nextcloud_Client.zip

When using the Nextcloud Desktop Client on macOS with Virtual Files enabled, uploading files larger than about 100 MB fails consistently.

The same files can be uploaded successfully through the Nextcloud web interface, and they can also be synchronized successfully with the Desktop Client when Virtual Files are disabled and a normal folder synchronization is used.

This makes the issue appear to be specific to the macOS Virtual Files / File Provider upload path in the Desktop Client.

I originally suspected a server-side upload limit, but I have verified that this is not the case:

• Cloudflare proxy is disabled (DNS only)
• uploads >100 MB work in the web interface
• PHP limits are set high enough (upload_max_filesize = 16G, post_max_size = 16G)
• reverse proxy upload size is not limited
• the problem only happens when Virtual Files are enabled on macOS

So the issue seems isolated to the Desktop Client on macOS when using Virtual Files.

Steps to reproduce

1. Install and configure the Nextcloud Desktop Client on macOS
2. Enable Virtual Files for the account
3. Connect the client to a Nextcloud server
4. Try to upload or sync a file larger than about 100 MB by placing it into the synchronized Nextcloud folder
5. Wait for the client to process and upload the file
6. Observe that the upload/sync does not complete successfully
7. Disable Virtual Files and switch the same account to normal folder synchronization
8. Try the same file again
9. Observe that the file now uploads successfully
10. Upload the same file via the Nextcloud web interface
11. Observe that the upload also succeeds there

Expected behavior

Files larger than 100 MB should upload successfully with the macOS Desktop Client when Virtual Files are enabled, just like they do:

• in the web interface
• and in the Desktop Client when normal folder synchronization is used

Which files are affected by this bug

Large media files are affected, especially: - .wav audio files - .m4a audio files - large project/media files above about 100 MB

Operating system

macOS

Which version of the operating system you are running.

Tahoe 26.4.1

Package

Official macOS 12+ universal pkg

Nextcloud Server version

33.0.2

Nextcloud Desktop Client version

33.0.2

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?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No obvious server-side upload limit errors were observed during successful web uploads.

The most important observation is:
- uploads >100 MB succeed via the web interface
- uploads >100 MB fail only in the macOS Desktop Client with Virtual Files enabled
- uploads >100 MB succeed in the Desktop Client when Virtual Files are disabled

PHP limits on the server:
- upload_max_filesize = 16G
- post_max_size = 16G

Reverse proxy upload size limit is disabled.

Additional info

Server setup:

• Nextcloud AIO
• reverse proxy in front of AIO
• Cloudflare proxy disabled (DNS only)
• web uploads of files >100 MB work correctly
• normal desktop synchronization of files >100 MB also works correctly

This strongly suggests that the issue is specific to the macOS Virtual Files / File Provider path in the Desktop Client.

I also tried creating a nextcloud.cfg manually to reduce chunk size, but that did not change the behavior. It is possible that this config file is not being used in the current macOS Virtual Files setup.

[i2h3]

This sounds very much like a regression because it used to work (before anyone brings it up: I have automated end-to-end tests in development to catch issues like this). The file provider extension builds on top of NextcloudKit which is also used for the iOS app. 100 MB sounds like a chunking limit. 🤔 This needs investigation.

[grisey]

I tested this with the following setup:

macOS: 26.4.1
Nextcloud Desktop Client: 33.0.3
Nextcloud revision: eb1e86f3b9f8a1df329023afa6aaf1fe3f010c6e

With Virtual Files / macOS File Provider enabled, I uploaded this file successfully:

filename: clonezilla-live-3.3.1-35-amd64.iso
size: 485490688 bytes

Relevant client log excerpt:

2026-05-04 16:06:24 Received file chunk size from server: 104857600
2026-05-04 16:06:24 Performing chunked upload to .../clonezilla-live-3.3.1-35-amd64.iso
2026-05-04 16:06:39 chunk 1 done
2026-05-04 16:06:45 chunk 2 done
2026-05-04 16:06:52 chunk 3 done
2026-05-04 16:06:58 chunk 4 done
2026-05-04 16:07:01 chunk 5 done
2026-05-04 16:07:09 successfully uploaded in chunks
2026-05-04 16:07:09 Successfully uploaded item with identifier: 00106471ocyyett612e6
filename: clonezilla-live-3.3.1-35-amd64.iso
size: 485490688

So I can not reproduce the >100 MB upload failure with this specific test on Desktop Client 33.0.3.

[Daehnie]

Thanks for the feedback and for testing.

I updated my macOS Desktop Client from 33.0.2 to 33.0.4 and repeated the same test with Virtual Files / macOS File Provider enabled.

The issue is no longer reproducible for me on 33.0.4.

Tested successfully:

• macOS Tahoe 26.4.1
• Nextcloud Desktop Client 33.0.4
• Nextcloud Server 33.0.2
• Virtual Files / macOS File Provider enabled
• File 1: 203,359,854 bytes
• File 2: 169,064,624 bytes

Relevant File Provider log excerpt:

Received file chunk size from server: 104857600
Performing chunked upload ...
chunkSize: 104857600
chunked upload starting...
chunk 1 done
chunk 2 done
successfully uploaded in chunks
Successfully uploaded item ...

So it looks like the problem was either fixed between 33.0.2 and 33.0.4, or the update/recreation of the macOS File Provider domain resolved a broken local File Provider state.

[camilasan]

if the issue occurs again, you can re-open the issue.
thanks for the feedback!

[Daehnie]

Additional update / retest:

I retested the issue with the current setup.

Environment:

• Nextcloud Desktop Client: 33.0.4
• Nextcloud Server: 33.0.5.1
• Virtual Files enabled
• macOS FileProvider / CloudStorage integration

The issue is still reproducible after the recent Nextcloud Server update.

Important findings:

1. A 100 MiB test file uploads successfully through the macOS FileProvider / Virtual Files folder.

   File size:

   104,857,600 bytes

   FileProvider log shows a successful create-item operation:

   create-item ... doc sz:104857600 ... ✅
   ul:uploaded

   The file appears in the Nextcloud web interface and the desktop client reports it as synchronized.

2. A 128 MiB test file fails reproducibly when placed into the same macOS FileProvider / Virtual Files folder.

   File size:

   134,217,728 bytes

   The FileProvider log repeatedly shows:

   NSFileProviderErrorDomain Code=-1005
   "The file does not exist"

3. Larger artificial test files also fail through the FileProvider upload path:

   • 128 MiB fails
   • 150 MiB fails
   • 200 MiB fails
   • 300 MiB fails
   • 650 MiB fails

4. The original affected file has a size of 653,081,290 bytes and also fails when placed locally into the FileProvider folder.

5. The exact same 653,081,290 byte file uploads successfully via direct WebDAV/curl and returns:

   HTTP/2 201 Created

6. After the successful WebDAV upload, the file appears correctly in Finder inside the Nextcloud FileProvider folder.

Conclusion:

The server, reverse proxy and WebDAV endpoint can handle the large file correctly. The issue appears to be specific to the local macOS FileProvider / Virtual Files upload path in the Nextcloud Desktop Client.

The failure seems to start somewhere above 100 MiB. A 100 MiB file works, while a 128 MiB file fails reproducibly with NSFileProviderErrorDomain Code=-1005.