Files > 1GB can be copied via davfs2 from filsystem to Nextcloud but where deleted ca. 10 seconds later

[CheckSP2NC]

Support intro

Sorry to hear you’re facing problems.

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

• Official documentation (searchable and regularly updated)
• How to topics and FAQs
• Forum search

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can.

The Basics

• Nextcloud Server version (32.0.2x)
• Operating system and version (wsl (debian 13) on windows server 2020)
• Web server and version (Apache 2.4.25):
• PHP version (8.4)

Summary of the issue you are facing:

In the meantime I have a little time to take care of my nextcloud problem.
And i found something stupid.

I’m running Nextcloud inside WSL on Windowws Server 2020.

In WSL(Debian) with ‘mount -t davfs’ i can use Nextcloud via /mnt/davfs/nv.

With this little script

#!/usr/bin/bash
file=$1
src=‘/mnt/c/_BigFile’
dst=‘/mnt/davfs/nc/_BigFile_davfs_Test’
if [ -f $dst/$file ]; then
rm $dst/$file*
fi
date
ls -la $dst
date
echo cp $src/$file $dst …
cp $src/$file $dst
date
echo cp $src/$file $dst ok.
secs=5
stop=0
until [ $stop -gt 60 ]
do
echo
date
ls -la $dst
echo sleep $secs Sekunden
sleep $secs
stop=$(($stop + $secs))
if [ ! -f $dst/$file ]; then
stop=61
fi
done
echo
date
ls -la $dst

i’m getting the follwing results

Copy File_1-0_GB.zip:

Fri Nov 28 01:10:17 PM CET 2025
total 2
drwxr-xr-x 2 root root 104 Nov 28 13:10 .
drwxr-xr-x 22 root root 824 Nov 28 13:06 ..
Fri Nov 28 01:10:17 PM CET 2025
cp /mnt/c/_BigFile/File_1-0_GB.zip /mnt/davfs/nc/_BigFile_davfs_Test …
Fri Nov 28 01:10:51 PM CET 2025
cp /mnt/c/_BigFile/File_1-0_GB.zip /mnt/davfs/nc/_BigFile_davfs_Test ok.

Fri Nov 28 01:10:51 PM CET 2025
total 1004304
drwxr-xr-x 2 root root 64 Nov 28 13:10 .
drwxr-xr-x 22 root root 824 Nov 28 13:06 ..
-rwxr-xr-x 1 root root 1028404992 Nov 28 13:10 File_1-0_GB.zip
sleep 5 Sekunden

…

Fri Nov 28 01:12:05 PM CET 2025
total 1004304
drwxr-xr-x 2 root root 104 Nov 28 13:11 .
drwxr-xr-x 22 root root 824 Nov 28 13:11 ..
-rwxr-xr-x 1 root root 1028404992 Nov 28 13:11 File_1-0_GB.zip
sleep 5 Sekunden

Fri Nov 28 01:12:11 PM CET 2025
total 1004304
drwxr-xr-x 2 root root 104 Nov 28 13:11 .
drwxr-xr-x 22 root root 824 Nov 28 13:11 ..
-rwxr-xr-x 1 root root 1028404992 Nov 28 13:11 File_1-0_GB.zip

Copy File_1-2_GB.zip:

Fri Nov 28 02:58:27 PM CET 2025
total 1004304
drwxr-xr-x 2 root root 104 Nov 28 13:11 .
drwxr-xr-x 22 root root 824 Nov 28 13:11 ..
-rwxr-xr-x 1 root root 1028404992 Nov 28 13:11 File_1-0_GB.zip
Fri Nov 28 02:58:27 PM CET 2025
cp /mnt/c/_BigFile/File_1-2_GB.zip /mnt/davfs/nc/_BigFile_davfs_Test …
Fri Nov 28 02:59:27 PM CET 2025
cp /mnt/c/_BigFile/File_1-2_GB.zip /mnt/davfs/nc/_BigFile_davfs_Test ok.

Fri Nov 28 02:59:27 PM CET 2025
total 2266939
drwxr-xr-x 2 root root 104 Nov 28 14:58 .
drwxr-xr-x 22 root root 824 Nov 28 13:11 ..
-rwxr-xr-x 1 root root 1028404992 Nov 28 13:11 File_1-0_GB.zip
-rwxr-xr-x 1 root root 1292938359 Nov 28 14:59 File_1-2_GB.zip
sleep 5 Sekunden

Fri Nov 28 02:59:33 PM CET 2025
total 2266939
drwxr-xr-x 2 root root 144 Nov 28 14:58 .
drwxr-xr-x 22 root root 824 Nov 28 13:11 ..
-rwxr-xr-x 1 root root 1028404992 Nov 28 13:11 File_1-0_GB.zip
-rwxr-xr-x 1 root root 1292938359 Nov 28 14:59 File_1-2_GB.zip
sleep 5 Sekunden

Fri Nov 28 02:59:42 PM CET 2025
total 1004304
drwxr-xr-x 2 root root 144 Nov 28 14:58 .
drwxr-xr-x 22 root root 824 Nov 28 13:11 ..
-rwxr-xr-x 1 root root 1028404992 Nov 28 13:11 File_1-0_GB.zip

As you can see, File_1-0_GB.zip ist successfully copied,

File_1-2_GB.zip ist also
succesfully copied, but was deleted after round about 10 secs.
The question is, who, the hell deteted the file in case of filesize > 1GB?

Nextclou logfile is not realy helpfull:

Fehler
no app in context
BadRequest
Expected filesize of 1292938359 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 0 bytes. Could either be a network problem on the send

Any ideas?

[jtr]

If I’m understanding your scenario correctly, the file was deleted locally by davfs2 once it failed to upload the file. AFAIK davfs2 does not support chunking so to upload larger files you’ll need to follow the uploading big files approach described in the Admin Manual to tune your infrastructure for non-chunked uploading.

[CheckSP2NC]

No, the file was deleted elsewhere in the cloud.

src=‘/mnt/c/_BigFile’ == local filesystem
dst=‘/mnt/davfs/nc/_BigFile_davfs_Test’ == nc cloud

For more confusion if have added the lines to my script:

bak=‘/mnt/c/_BigFile_davfs’
echo cp $dst/$file $bak
cp $dst/$file $bak &

And when the script ends this is the content of

‘/mnt/c/_BigFile_davfs’ == local filesystem

total 5958944
drwxrwxrwx 1 gasthd gasthd 4096 Nov 28 21:03 .
drwxrwxrwx 1 gasthd gasthd 4096 Nov 28 19:48 ..
-rwxrwxrwx 1 gasthd gasthd 1028404992 Nov 28 20:54 File_1-0_GB.zip
-rwxrwxrwx 1 gasthd gasthd 1292894208 Nov 28 20:57 File_1-2_GB.zip
-rwxrwxrwx 1 gasthd gasthd 1459355648 Nov 28 21:04 File_1-4_GB.zip

It was time enough to copy the files to local filesystem bevor the file in the cloud was deleted.

And the nextlod log said:

Fehler	no app in context	BadRequestExpected filesize of 1292938359 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 0 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.

Fehler	no app in context	BadRequestExpected filesize of 1459375159 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 0 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.

But the files where successfully copie from the cloud to the locl filesystem

[jtr]

Davfs2 initially places the file that you’re trying to send to Nextcloud within a local cache layer. When the upload is denied/fails (for the reasons I previously hinted at), davfs2 removes the file from its local cache since it’s not really in Nextcloud.

[Mornsgrans]

@CheckSP2NC

BadRequestExpected filesize of 1292938359 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 0 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.

Maybe that is the solution:

Error "Bad Request: Expected File Size..."

Hey, currently I setup my own Nextcloud (self-hosted). But when uploading large files > 500 MB, I receive this error: BadRequest Expected filesize of 2708731595 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 0 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side. I’m aware there are many other people dealing with the same issue, but yet I couldn’t find a solution in those topics. Occourance: I start …

Annother possible solution:

BadRequest Expected filesize of x bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) y bytes

@pitsinis I ran into the same problem. My setup also uses Traefik with Docker containers, and I discovered that the issue started with Traefik version 2.11.2. Its default respondingTimeouts now set the readTimeout to 60 seconds. I fixed it by adding these lines to my compose: services: traefik: command: - --entrypoints.web.transport.respondingTimeouts.readTimeout=0 - --entrypoints.websecure.transport.respondingTimeouts.readTimeout=0 For reference, see the Traefik migration …

(Google search for “BadRequestExpected filesize of bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 0 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.”