[Solved] Yet another `Sabre\\DAV\\Exception\\BadRequest`: Expected filesize of... but only on Windows

ℹ️ Support
, , , , , ,
1

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 33.0.3.2
  • Operating system and version (e.g., Ubuntu 24.04):
    • Debian Trixie
  • Web server and version (e.g, Apache 2.4.25):
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • none
  • PHP version (e.g, 8.3):
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • Right around using the Windows Files client
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO and baremetal
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No. I shouldn't have mod_security enabled, but I am using DNS ssigned SSL certificates if that matters.

Summary of the issue you are facing:

Sabre\\DAV\\Exception\\BadRequest: Expected filesize of 66737304 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 53805056 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.

I’ve been having this issue on both the AIO and on a baremetal installation (all AIO containers have been then stopped and their autorestart disabled).

The problem appears when attempting to upload from a Windows 11 Client Files app files bigger than some MBs, but it also fails almost immediately too (we’re talking 3-5 MB). My server is on the same network, but I only access it through my DNS, hence I am stuck at 20 MBps client upload / 80 MBps host download.

The problem does not seem to appear on an Android client, no matter how many folders or big files I upload at a time. It is reproducible every time on a Web Browser from Windows (Edge / Brave).

I am running on OpenZFS on a single SSD. Tell me if you need any information about my filesystem.

No VPN. No antivirus beside Windows Defender at the time of testing.

Log entries

Nextcloud 
{
	"reqId": "iqUaB78wED2WyMF69SXV",
	"level": 3,
	"time": "2026-05-14T07:41:28+00:00",
	"remoteAddr": "redactedIP",
	"user": "admin",
	"app": "no app in context",
	"method": "PUT",
	"url": "/remote.php/dav/files/admin/Test2/DONE_mb_driver_597_chipset_5.11.02.217/mb_driver_597_chipset_5.11.02.217.exe",
	"scriptName": "/remote.php",
	"message": "Expected filesize of 66737304 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 53805056 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.",
	"userAgent": "Mozilla/5.0 (Windows) mirall/33.0.4 (build 20260504) (Nextcloud, windows-10.0.26200 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
	"version": "33.0.3.2",
	"clientReqId": "516b71e8-b0c5-4cad-89ba-c2f5bf0aa403",
	"exception": {
		"Exception": "Sabre\\DAV\\Exception\\BadRequest",
		"Message": "Expected filesize of 66737304 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 53805056 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.",
		"Code": 0,
		"Trace": [
			{
				"file": "/var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php",
				"line": 126,
				"function": "put",
				"class": "OCA\\DAV\\Connector\\Sabre\\File",
				"type": "->"
			},
			{
				"file": "/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
				"line": 1098,
				"function": "createFile",
				"class": "OCA\\DAV\\Connector\\Sabre\\Directory",
				"type": "->",
				"args": [
					"*** sensitive parameters replaced ***"
				]
			},
			{
				"file": "/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php",
				"line": 504,
				"function": "createFile",
				"class": "Sabre\\DAV\\Server",
				"type": "->",
				"args": [
					"*** sensitive parameters replaced ***"
				]
			},
			{
				"file": "/var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
				"line": 89,
				"function": "httpPut",
				"class": "Sabre\\DAV\\CorePlugin",
				"type": "->"
			},
			{
				"file": "/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
				"line": 472,
				"function": "emit",
				"class": "Sabre\\DAV\\Server",
				"type": "->"
			},
			{
				"file": "/var/www/nextcloud/apps/dav/lib/Connector/Sabre/Server.php",
				"line": 212,
				"function": "invokeMethod",
				"class": "Sabre\\DAV\\Server",
				"type": "->"
			},
			{
				"file": "/var/www/nextcloud/apps/dav/lib/Server.php",
				"line": 428,
				"function": "start",
				"class": "OCA\\DAV\\Connector\\Sabre\\Server",
				"type": "->"
			},
			{
				"file": "/var/www/nextcloud/apps/dav/appinfo/v2/remote.php",
				"line": 25,
				"function": "exec",
				"class": "OCA\\DAV\\Server",
				"type": "->"
			},
			{
				"file": "/var/www/nextcloud/remote.php",
				"line": 151,
				"args": [
					"/var/www/nextcloud/apps/dav/appinfo/v2/remote.php"
				],
				"function": "require_once"
			}
		],
		"File": "/var/www/nextcloud/apps/dav/lib/Connector/Sabre/File.php",
		"Line": 261,
		"message": "Expected filesize of 66737304 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 53805056 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.",
		"exception": "{\"class\":\"Sabre\\DAV\\Exception\\BadRequest\",\"message\":\"Expected filesize of 66737304 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 53805056 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.\",\"code\":0,\"file\":\"/var/www/nextcloud/apps/dav/lib/Connector/Sabre/File.php:261\",\"trace\":\"#0 /var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php(126): OCA\\DAV\\Connector\\Sabre\\File->put()\\n#1 /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php(1098): OCA\\DAV\\Connector\\Sabre\\Directory->createFile()\\n#2 /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php(504): Sabre\\DAV\\Server->createFile()\\n#3 /var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php(89): Sabre\\DAV\\CorePlugin->httpPut()\\n#4 /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php(472): Sabre\\DAV\\Server->emit()\\n#5 /var/www/nextcloud/apps/dav/lib/Connector/Sabre/Server.php(212): Sabre\\DAV\\Server->invokeMethod()\\n#6 /var/www/nextcloud/apps/dav/lib/Server.php(428): OCA\\DAV\\Connector\\Sabre\\Server->start()\\n#7 /var/www/nextcloud/apps/dav/appinfo/v2/remote.php(25): OCA\\DAV\\Server->exec()\\n#8 /var/www/nextcloud/remote.php(151): require_once('...')\\n#9 {main}\"}",
		"CustomMessage": "Expected filesize of 66737304 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 53805056 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side."
	},
	"id": "6a057ccaaaf05"
}

These are the only details that I’ve found to be be useful. There’s nothing else after them, and old logs seem not to show much. I have the past AIO logs that I can also show.

Web server - /var/log/apache2/error.log

EDIT: these graceful restarts are for config changes. Nothing to see here. I can provide more details should you ask for them.

[Thu May 14 08:08:12.541299 2026] [mpm_prefork:notice] [pid 4794:tid 4794] AH00171: Graceful restart requested, doing res>
[Thu May 14 08:08:12.596910 2026] [mpm_prefork:notice] [pid 4794:tid 4794] AH00163: Apache/2.4.67 (Debian) OpenSSL/3.5.5 >
[Thu May 14 08:08:12.596954 2026] [core:notice] [pid 4794:tid 4794] AH00094: Command line: '/usr/sbin/apache2'
[Thu May 14 08:16:44.177931 2026] [mpm_prefork:notice] [pid 4794:tid 4794] AH00171: Graceful restart requested, doing res>
[Thu May 14 08:16:44.239123 2026] [mpm_prefork:notice] [pid 4794:tid 4794] AH00163: Apache/2.4.67 (Debian) OpenSSL/3.5.5 >
[Thu May 14 08:16:44.239151 2026] [core:notice] [pid 4794:tid 4794] AH00094: Command line: '/usr/sbin/apache2'

Configuration

Nextcloud

occ config:list system 
{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "33.0.3.2",
        "overwrite.cli.url": "http:\/\/localhost",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "loglevel": 2,
        "maintenance": false,
        "maintenance_window_start": 6,
        "default_phone_region": "IT",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "mail_sendmailmode": "smtp",
        "mail_smtpstreamoptions": {
            "ssl": {
                "allow_self_signed": true,
                "verify_peer": false,
                "verify_peer_name": false
            }
        }
    }
}

Apps

occ app:list 
Enabled:
  - activity: 6.0.0
  - app_api: 33.0.0
  - bruteforcesettings: 6.0.0
  - circles: 33.0.0
  - cloud_federation_api: 1.17.0
  - comments: 1.23.0
  - contactsinteraction: 1.14.1
  - dashboard: 7.13.0
  - dav: 1.36.0
  - federatedfilesharing: 1.23.0
  - federation: 1.23.0
  - files: 2.5.0
  - files_downloadlimit: 5.1.0
  - files_pdfviewer: 6.0.0
  - files_reminders: 1.6.0
  - files_sharing: 1.25.2
  - files_trashbin: 1.23.0
  - files_versions: 1.26.0
  - firstrunwizard: 6.0.0
  - logreader: 6.0.0
  - lookup_server_connector: 1.21.0
  - nextcloud_announcements: 5.0.0
  - notifications: 6.0.0
  - oauth2: 1.21.0
  - password_policy: 5.0.0
  - photos: 6.0.0
  - privacy: 5.0.0
  - profile: 1.2.0
  - provisioning_api: 1.23.0
  - recommendations: 6.0.0
  - related_resources: 4.0.0
  - serverinfo: 5.0.0
  - settings: 1.16.0
  - sharebymail: 1.23.0
  - support: 5.0.0
  - survey_client: 5.0.0
  - systemtags: 1.23.0
  - text: 7.0.1
  - theming: 2.8.0
  - twofactor_backupcodes: 1.22.0
  - twofactor_totp: 15.0.0
  - updatenotification: 1.23.0
  - user_status: 1.13.0
  - viewer: 6.0.0
  - weather_status: 1.13.0
  - webhook_listeners: 1.5.0
  - workflowengine: 2.15.0
Disabled:
  - admin_audit: 1.23.0
  - encryption: 2.21.0
  - files_external: 1.25.1
  - suspicious_login: 11.0.0
  - testing: 1.23.0
  - twofactor_nextcloud_notification: 7.0.0
  - user_ldap: 1.24.0

Others

How I have customized php.ini so far:

`/etc/php/8.4/apache2/php.ini` 
[PHP]

memory_limit = 512M

[opcache]

opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=1

I hope that somebody can help me. I have a hefty sys admin handbook that I am compiling or editing every time I do something, keeping track of virtually any change that I’ve done so far.
I can and will provide anything you ask (well, not my sensitive data :3 )

I am UTC+2, so if times do not coincide it might be for this reason.

2

This error simply says that during the upload the app has been closed or a problem in the network. Nextcloud will try it again and you don’t have to do something

3

Thank you for replying. Maybe you mean just the last Apache logs? Now that I think about it, the graceful restarts were for my configuration reloads, hence you’re right. I’ll take them out of the thread.

I haven’t been able to solve the ‘BadRequest’ for the past days. It’s completely unusable from Windows.

4

Before anything else, your network situation is not clear from the post. A few questions that would help significantly:

  • Is your Nextcloud server on your local network, or is it hosted elsewhere?
  • How is your DNS set up? Does your domain resolve to your public IP even from inside your own network, or do you have a local DNS server (e.g. Pi-hole, dnsmasq) that returns the server’s internal IP directly?
  • When you tested with Android, were you on the same WiFi network as the server, or on mobile data?

The answer to the last question matters a lot: if Android was on mobile data, it takes a completely different path to the server, and the fact that it works tells us nothing about the server-side configuration. If Android was on the same WiFi, then server-side configuration is effectively ruled out and the problem is Windows-specific.

If your server is local and your DNS resolves your domain to your public IP even from inside the network, your traffic goes through hairpin NAT on your router (your packet leaves toward the router’s public IP and gets forwarded back in). Some routers handle this poorly under sustained load.

To test whether this is the issue, temporarily add an entry to your Windows hosts file that maps your domain directly to the server’s local IP — this bypasses the router entirely while keeping the domain name intact, so TLS and Nextcloud’s trusted_domains check will still work.

The hosts file is at C:\Windows\System32\drivers\etc\hosts and requires administrator rights to edit. The easiest way: open it with Notepad++, which will automatically ask for elevation when you try to save. Alternatively, open Notepad as Administrator (right-click → “Run as administrator”) and then open the file manually.

Add this line:

192.168.x.y  cloud.yourdomain.tld

Replace 192.168.x.y with your server’s local IP. Retry the upload, then remove the line afterward.

One more thing: you mentioned no antivirus was running, but Windows Defender has components that are independent of the antivirus scanner — specifically Network Protection and SmartScreen. These operate at the OS network layer and can interfere with file transfers even when real-time protection is off.

ernolf

5

Very well detailed post, thank you @ernolf

  • Is your Nextcloud server on your local network, or is it hosted elsewhere?

It is hosted on my home, local network.

  • How is your DNS set up? Does your domain resolve to your public IP even from inside your own network, or do you have a local DNS server (e.g. Pi-hole, dnsmasq) that returns the server’s internal IP directly?

All the connections (including my own Nextcloud instance authentication and file synchronization) is done by DNS which points to my public, static IP with simple A/AAAA records, without the use of any DDNS or personal DNS servers.

  • When you tested with Android, were you on the same WiFi network as the server, or on mobile data?

Both on both. I’ve just tested the desktop with a wired hotspot by cellular network and, albeit at a faster speed and at a later time, I still encounter the error.
The smartphone’s client works on either networks.

[…] temporarily add an entry to your Windows hosts file that maps your domain directly to the server’s local IP.

Success. 886 MB, 348 files and 134 folders later, I’ve had no error. I require more extensive tests, but this result is very promising.

Some routers handle this [hairpin NAT] poorly under sustained load.

I think we’re coming closer to the solution. I have just remember that I used NordVPN on both my cellphone and my desktop, although Windows does routing differently with that since I was able to reach my modem (different subnet) with Android, but not with Windows.

I have very recently formatted my Windows partition (and, now that I remember, I also have a Debian partition…) in which I don’t use Nord anymore.

Also, my OpenWRT based router is the only device welcoming internet traffic from my modem-router, which opens all its ports to it and forwards everything.

I have tried without any VPN on my phone, and I immediately got the errors. The Android client is built in such a way that silently ceases to upload, with no prompted error. Immediately after resuming cellular data, the upload started and completed without any Errors in the NC admin console.

I will definitely try on Debian and I will also have a look around my NAT settings on my GL-iNET router.

EDIT: drop-in gateway has always been disabled. I have no idea what it does, looking into it rn.
EDIT2: Full Cone NAT and SIP ALG are disabled. IP rebind protection is off on main router-modem.

6

This confirms the diagnosis: the issue is hairpin NAT on your GL-iNET router.

Why VPN worked: NordVPN routes all traffic through an external server, so uploads effectively came from outside your network — no hairpin involved. Without VPN, traffic from inside your LAN hits the router’s public IP, gets NAT’d back in, and your router struggles with sustained large transfers through that path.

Why Android on WiFi without VPN now fails too: Exactly as expected — same network, same hairpin path, same problem. It is not a Windows issue.

The proper fix: split DNS on your GL-iNET router

Your GL-iNET router has a built-in feature for this. In the router’s web interface, go to:

Network → DNS → Edit Hosts

Add an entry that maps your Nextcloud domain to your server’s local IP address. This tells all devices on your network to connect to the server directly, completely bypassing the hairpin NAT path.

Documentation: DNS - GL.iNet Router Docs 4

Important: On the same DNS page, there is a toggle called “DNS Rebinding Attack Protection”. This feature is designed to block exactly what we are trying to do — returning a local IP for a public domain name. If your Hosts entry does not seem to take effect, try disabling this toggle.

Once configured, the Windows hosts file entry you added for testing can be removed — the router will handle it for all devices automatically.

ernolf