Uploading more than 100mb using foldersync(WebDAV)

[Manhandled]

Hello!

I am using the Docker AIO latest build setup fully updated on a VPS.

My issue is that the official Nextcloud app for android is pretty lackluster in terms of folder syncing which forced me to buy another app to handle this specific part(“foldersync”). This app natively supports Nextcloud but seems to upload through WebDAV.

As soon as I try to upload files larger than exactly 100mb, the upload just fails and restarts which seems to indicate some sort of upload limit. How can I raise or disable this limit? Thank you very much!

[jtr]

Unfortunately you seem to have overlooked the support template which asks some questions that would help pinpoint the underlying cause.

Wild guess: you’re using Cloudflare?

See here.

[Manhandled]

Hi @jtr and thank you for your reply. I will try to post information in form of the provided template. I can answer you question beforehand: I do not use Cloudflare at this moment because of peering issues in the free plan with my current ISP (Deutsche Telekom)

• Nextcloud Server version: 31
• Operating system and version: 24.04.2 LTS
• Is this the first time you’ve seen this error? (Yes / No): Yes
• When did this problem seem to first start? After uploading a file greater than 100MB not using the official android Nextcloud app but with foldersync (apparently through WebDAV)
• Installation method: AIO
• Are you using Cloudflare, mod_security, or similar? No

History:

I deployed an up-to-date AIO Nextcloud instance on one VPS root server(8 cores/16gb/1tb ssd) with docker using the official installation guide. The NC Data-dir is on a different cloud hoster. This storage is mounted per fstab and cifs to the nextcloud host. The connection between those two servers exceeds 2gbit/s most of the times and so far I could not make out any other issues. This setup is secured with CrowdSec running on the host besides docker. The files are secured with the built in ClamAV from the AIO instance.

I have been running this exact setup for roughly two weeks now with one AIO update done in between.

I have initially used the official android app to upload several pictures and videos of varying size with several files being bigger than 100mb. Due to different issues with this app (files being ignored and syncing not starting properly without app restart or resetting) I moved to another app being recommended (foldersync). Except for files larger than 100MB, I have no other syncing problems anymore.

Nextcloud Log:

Fehlersuche	webdav	
NotAuthenticated
No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured

This is the only entry that I would vaguely link to my issue but it appeared with a timestamp 7 minutes after the fourth failed upload attempt. There were no entries written during the failed upload attempts.

Config:

{
    "system": {
        "one-click-instance": true,
        "one-click-instance.user-limit": 100,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "check_data_directory_permissions": false,
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "overwritehost": "<fqdn>",
        "overwriteprotocol": "https",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "<fqdn>"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "31.0.2.1",
        "overwrite.cli.url": "<fqdn>",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "loglevel": 2,
        "log_type": "file",
        "logfile": "\/var\/www\/html\/data\/nextcloud.log",
        "log_rotate_size": 10485760,
        "log.condition": {
            "apps": [
                "admin_audit"
            ]
        },
        "preview_max_x": 2048,
        "preview_max_y": 2048,
        "jpeg_quality": 60,
        "enabledPreviewProviders": {
            "1": "OC\\Preview\\Image",
            "2": "OC\\Preview\\MarkDown",
            "3": "OC\\Preview\\MP3",
            "4": "OC\\Preview\\TXT",
            "5": "OC\\Preview\\OpenDocument",
            "6": "OC\\Preview\\Movie",
            "7": "OC\\Preview\\Krita",
            "0": "OC\\Preview\\Imaginary",
            "23": "OC\\Preview\\ImaginaryPDF"
        },
        "enable_previews": true,
        "upgrade.disable-web": true,
        "mail_smtpmode": "smtp",
        "trashbin_retention_obligation": "auto, 30",
        "versions_retention_obligation": "auto, 30",
        "activity_expire_days": 30,
        "simpleSignUpLink.shown": false,
        "share_folder": "\/Shared",
        "one-click-instance.link": "https:\/\/nextcloud.com\/all-in-one\/",
        "upgrade.cli-upgrade-link": "https:\/\/github.com\/nextcloud\/all-in-one\/discussions\/2726",
        "updatedirectory": "\/nc-updater",
        "maintenance_window_start": 100,
        "allow_local_remote_servers": true,
        "davstorage.request_timeout": 3600,
        "documentation_url.server_logs": "https:\/\/github.com\/nextcloud\/all-in-one\/discussions\/5425",
        "htaccess.RewriteBase": "\/",
        "dbpersistent": false,
        "auth.bruteforce.protection.enabled": true,
        "ratelimit.protection.enabled": true,
        "files_external_allow_create_new_local": true,
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "preview_imaginary_url": "***REMOVED SENSITIVE VALUE***",
        "preview_imaginary_key": "***REMOVED SENSITIVE VALUE***",
        "updater.release.channel": "stable",
        "app_install_overwrite": [
            "nextcloud-aio",
            "money"
        ],
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": true,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "forbidden_filename_basenames": [
            "con",
            "prn",
            "aux",
            "nul",
            "com0",
            "com1",
            "com2",
            "com3",
            "com4",
            "com5",
            "com6",
            "com7",
            "com8",
            "com9",
            "com\u00b9",
            "com\u00b2",
            "com\u00b3",
            "lpt0",
            "lpt1",
            "lpt2",
            "lpt3",
            "lpt4",
            "lpt5",
            "lpt6",
            "lpt7",
            "lpt8",
            "lpt9",
            "lpt\u00b9",
            "lpt\u00b2",
            "lpt\u00b3"
        ],
        "forbidden_filename_characters": [
            "<",
            ">",
            ":",
            "\"",
            "|",
            "?",
            "*",
            "\\",
            "\/"
        ],
        "forbidden_filename_extensions": [
            " ",
            ".",
            ".filepart",
            ".part"
        ],
        "memories.db.triggers.fcu": true,
        "memories.exiftool": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/exiftool-amd64-musl",
        "memories.vod.path": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/go-vod-amd64",
        "memories.vod.ffmpeg": "\/usr\/bin\/ffmpeg",
        "memories.vod.ffprobe": "\/usr\/bin\/ffprobe",
        "memories.vod.disable": false,
        "DOMAIN": "<domain>"
    }
}

If there are better logs to show, please point me to it because I cannot seem to access the apache logs in the apache container with the methods I tried so far. The container logs themselves show no issues.

[vawaver]

It is a lot for the detailed description — it really helps narrow things down.

Based on what you’ve shared, here are several areas worth investigating to fix the issue with uploads larger than 100 MB via FolderSync (WebDAV):

---

1. FolderSync likely doesn’t support chunked uploads

Many WebDAV clients (including FolderSync) do not support chunked uploading, which means files are uploaded in one single PUT request. This can lead to failures with larger files, especially over long connections or through certain storage types.

Check if FolderSync has an option like “streamed upload” or anything similar in its settings.
Try a different WebDAV client like Cyberduck, rclone, or even the Nextcloud desktop app to compare behavior.

---

2. Authentication issue in the logs

You mentioned this log entry:

No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured

This might indicate:

• FolderSync dropped the session during upload.
• The WebDAV request was malformed or timed out.
• A service like CrowdSec or a proxy is stripping or modifying headers.

Try temporarily disabling CrowdSec and reattempt the upload.
If you’re using a reverse proxy, make sure it doesn’t remove the Authorization header.

---

3. CIFS mount might be the weak link

Your Nextcloud data/ directory is mounted via CIFS over fstab from another host. While your bandwidth is excellent (2 Gbit/s), CIFS is known to have issues with performance, buffering, and locking — especially when handling large, single-write uploads like with WebDAV PUT.

Try uploading a large file (e.g., 200 MB) via:

• The Nextcloud web interface, or
• The official Android or desktop app.

If it works there, but not via FolderSync, the issue is client-side.
If it also fails, the issue likely lies with the CIFS mount.

In that case, consider:

• Using NFS instead of CIFS (better performance and stability for server tasks).
• Or relocating the AIO instance directly onto the server with the data.

---

4. Verify PHP and web server limits (inside the container)

Since you’re using AIO, the limits should be reasonable, but you can double-check inside the nextcloud-aio-nextcloud container:

php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"

Ensure these values are at least 512M or higher.

---

5. Client-side timeout in FolderSync

Your Nextcloud config contains:

"davstorage.request_timeout": 3600

That’s fine on the server side. However, FolderSync might have its own internal timeout that kills the upload before it completes. Check for timeout-related settings in the app.

---

Summary of recommendations:

Area	Action
FolderSync	Likely doesn’t support chunked WebDAV – try other clients
Authentication	Check if headers are stripped or session is lost mid-upload
CIFS mount	Consider switching to NFS or testing with local data directory
PHP/web server	Ensure high upload/post/memory limits in the container
Timeout	Check FolderSync for any upload timeout setting
CrowdSec	Temporarily disable to rule out interference

[Manhandled]

Thank you for your answer.

I verified the server limits:

memory_limit => 4096M => 4096M
post_max_size => 1000G => 1000G
upload_max_filesize => 1000G => 1000G

I tried adjusting the foldersync options and can give some additional information:

To preface this: Smaller files like pictures and short videos are still getting synced successfully through the WebDAV connection in this very moment.

I tried setting the chunk size in the app from 100MB to 75MB, 50MB and even 10MB. This lead to the upload lasting for exactly those values, e.g. at 75MB, the upload would just restart after reaching those 75MB and so on.

Disabling chunking inside of foldersync altogether is not working . This lead to larger files seemingly uploading completely in the app gui and then still restarting. Those files do not appear in Nextcloud so the upload indeed failed.

My last resort was circumventing Nextcloud by uploading the files through SMB3 to the folder Nextcloud uses for Photos. These files get uploaded successfully no matter the size but do not appear in Nextcloud.

I would have to do the occ command to reindex everytime I upload photos which does not seem sensible to me.

Is there any other way to troubleshoot this?

[vawaver]

Hi again and thank you for your thorough testing — your findings really help narrow this down.

---

Quick question before going further:

Have you tried uploading the same large files using the official Nextcloud desktop client (Windows/Linux/macOS)?

This client uses Nextcloud’s native chunked upload mechanism, which should handle large files reliably and would confirm whether the issue is specific to FolderSync or more general (e.g., related to storage/backend performance).

If you haven’t tried it yet, I strongly recommend doing so — even just as a test — to compare behavior.

---

Summary of current findings and suggestions

1. FolderSync’s “chunking” is not compatible

As you already discovered, FolderSync slices the file at the client side, but does not follow the WebDAV chunking method used by Nextcloud. That’s why uploads restart or fail after reaching the chunk size limit.

This confirms that FolderSync is not suitable for large file uploads to Nextcloud over WebDAV.

2. SMB3 uploads bypass Nextcloud and require manual indexing

Files uploaded directly to the data directory (e.g., over SMB3) will not show up in the web interface unless you manually run:

docker exec -it nextcloud-aio-nextcloud php occ files:scan --path="username/files/Photos"

This is expected behavior, as Nextcloud does not monitor the file system directly.

---

Recommendations

Option	What to try
Official desktop client	Check if upload succeeds with proper chunking
rclone / Cyberduck	Better WebDAV clients with chunking support
External Storage App	Mount remote SMB/SFTP shares via UI, with full indexing
Avoid FolderSync for large files	It doesn’t support Nextcloud-style chunking
Avoid SMB uploads for users	They require occ files:scan and can break consistency

---

Let us know if you’ve already tested the official client — and if not, what results you get with it.

[Manhandled]

Hi!

I already tried the official app and indeed it syncs larger files. My problem is that it is generally less reliable. On one occasion I had to reset the app completely to make it sync again because it did not find files on my phone anymore.

Are there other proven-to-work sync clients for android and nextcloud for me to use? FolderSync was recommended on many different threads which is why I bought it.

[vawaver]

Hey, just wanted to jump in and share my experience in case it helps.

I’m actually using the official Nextcloud Android client, but I installed it from F-Droid, not the Play Store.
In the past, I had problems with the Play Store version – especially with photo uploads from the phone not syncing reliably – but the F-Droid version has been much more consistent for me.

Also, from what I’ve seen, network quality makes a big difference when syncing large files or uploading photos.

• On Wi-Fi networks with slow upload speeds (under 10 Mbit), I often run into failed uploads or long delays.
• But as soon as I switch to a faster Wi-Fi (like 50–100 Mbit+), everything works smoothly.
• Same goes for mobile data – both 4G and 5G work great in my case, no problems with syncing at all.

So maybe it’s worth testing whether the issue is linked to your connection quality when the app fails to detect or upload files.

[Manhandled]

Thanks for sharing your experience!

I have also been using the F-Droid-version and despite granting permission to all files the official nextcloud app failed to consistently sync at times. I will certainly give it a try again if there are reported improvements to this.

Given that the SMB3-method worked flawlessly using the same phone, app and Wifi I would guess that the problem lies elsewhere. My Wifi is pretty solid across all devices, my internet connection is indeed capped at 10MBit/s upload.

If there really is a problem linked between the nextcloud app and my network connection, that is all the more reason to use another app or troubleshoot the WebDAV-implementation of Nextcloud.

[Manhandled]

I pondered a bit over this and after trying the occ files:scan-command I think I will use this workaround that works best for my already set up folder structure:

• I have a folder on a cifs mounted cloud storage (also ncdata directory) with respective subfolders which is used to hold freshly uploaded photos and videos from the camera and several messengers
• This folder will be emptied manually as I sort the files into their respective folders/albums
• Using Foldersync with SMB3 Protocol, I upload directly to this storage bypassing Nextcloud completely
• I created a crontab running every hour which runs the files:scan command for this specific folder so that Nextcloud is aware of the new files, this command runs for 2 seconds for 1500 files. This is acceptable for me