Files uploaded by WEBDAV are 0 sized in DB (also web interface), but on storage are OK.

[biware-repo]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

1. Run WebDAV client and create connection to NC instance
2. Copy some files to NC
3. Files have zero size, the 0 is in also in oc_filecache
4. The physical storage show the proper size of files and content is OK

Expected behaviour

The files should have proper size in web interface, also webdav client should show the proper size of file after upload.

Actual behaviour

There 0 in size of uploaded files in web interface and also webdav client show 0

Server configuration

Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (4 cores) - Virtual machine 16 GB RAM 4 TB SSD Intel (RAID 5)

Operating system: UBUNTU 18.04.4 LTS (Bionic Beaver) Linux 4.15.0-99-generic x86_64

Web server: Apache 2.4.29

Database: MariaDB 10.1.44

PHP version: PHP 7.2.24

Nextcloud version: (see Nextcloud admin page) 19.0.0

Updated from an older Nextcloud/ownCloud or fresh install: Updated from 18.0.5

Where did you install Nextcloud from: Updated with updater from admin interface.

Signing status:

Signing status

``` No errors have been found. ```

List of activated apps:

App list

``` - accessibility: 1.5.0 - activity: 2.12.0 - calendar: 2.0.3 - cloud_federation_api: 1.2.0 - comments: 1.9.0 - contactsinteraction: 1.0.0 - dav: 1.15.0 - extract: 1.2.4 - federatedfilesharing: 1.9.0 - files: 1.14.0 - files_accesscontrol: 1.9.0 - files_automatedtagging: 1.9.0 - files_external: 1.10.0 - files_pdfviewer: 1.8.0 - files_rightclick: 0.16.0 - files_sharing: 1.11.0 - files_trashbin: 1.9.0 - files_versions: 1.12.0 - files_videoplayer: 1.8.0 - flowupload: 1.0.0 - groupfolders: 6.0.6 - impersonate: 1.6.0 - logreader: 2.4.0 - lookup_server_connector: 1.7.0 - notifications: 2.7.0 - oauth2: 1.7.0 - onlyoffice: 4.2.0 - password_policy: 1.9.1 - photos: 1.1.0 - previewgenerator: 2.3.0 - privacy: 1.3.0 - provisioning_api: 1.9.0 - serverinfo: 1.9.0 - settings: 1.1.0 - side_menu: 1.7.0 - systemtags: 1.9.0 - text: 3.0.1 - theming: 1.10.0 - theming_customcss: 1.6.0 - twofactor_backupcodes: 1.8.0 - updatenotification: 1.9.0 - user_ldap: 1.9.0 - viewer: 1.3.0 - workflow_script: 1.4.0 - workflowengine: 2.1.0 ```

Nextcloud configuration:

Config report

``` { "system": { "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "***REMOVED SENSITIVE VALUE***", "***REMOVED SENSITIVE VALUE***", "***REMOVED SENSITIVE VALUE***", "***REMOVED SENSITIVE VALUE***", ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",, "dbtableprefix": "oc_", "installed": true, "instanceid": "***REMOVED SENSITIVE VALUE***", "mail_smtpmode": "smtp", "remember_login_cookie_lifetime": "1800", "log_rotate_size": "10485760", "simpleSignUpLink.shown": "false", "memcache.local": "\\OC\\Memcache\\Redis", "filelocking.enabled": true, "memcache.distributed": "\\OC\\Memcache\\Redis", "memcache.locking": "\\OC\\Memcache\\Redis", "trashbin_retention_obligation": "14,31", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 0, "timeout": 0.5, "dbindex": 0, "password": "***REMOVED SENSITIVE VALUE***" }, "htaccess.RewriteBase": "\/", "enable_previews": true, "preview_libreoffice_path": "\/usr\/bin\/libreoffice", "maintenance": false, "skeletondirectory": "core\/skeleton", "mail_sendmailmode": "smtp", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtpauthtype": "LOGIN", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "587", "ldapIgnoreNamingRules": false, "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory", "updater.release.channel": "beta", "theme": "", "loglevel": 2, "app_install_overwrite": [ "onlyoffice", "ldapcontacts", "files_reader" ], "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "mysql.utf8mb4": true, "version": "19.0.0.12", "has_rebuilt_cache": true, "mail_smtpsecure": "tls", "mail_smtpauth": 1, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***" } } ```

Are you using external storage, if yes which one: local

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: Chrome 83.0.4103.61

Operating system: Windows 10 1903

Logs

Web server error log

Web server error log

``` [Mon Jun 08 06:25:10.071564 2020] [mpm_event:notice] [pid 36008:tid 140286657182656] AH00489: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations [Mon Jun 08 06:25:10.071602 2020] [core:notice] [pid 36008:tid 140286657182656] AH00094: Command line: '/usr/sbin/apache2' [Mon Jun 08 07:27:01.674808 2020] [access_compat:error] [pid 7408:tid 140285686302464] [client 213.81.157.70:49978] AH01797: client denied by server configuration: /var/www/nextcloud/config [Mon Jun 08 09:03:29.013712 2020] [access_compat:error] [pid 7408:tid 140285703087872] [client 95.105.172.148:53674] AH01797: client denied by server configuration: /var/www/nextcloud/config [Mon Jun 08 09:40:42.730314 2020] [access_compat:error] [pid 7409:tid 140286222051072] [client 194.154.241.247:53276] AH01797: client denied by server configuration: /var/www/nextcloud/config [Mon Jun 08 10:01:14.452407 2020] [access_compat:error] [pid 7408:tid 140285174609664] [client 194.154.248.129:58895] AH01797: client denied by server configuration: /var/www/nextcloud/config [Mon Jun 08 12:59:44.608673 2020] [access_compat:error] [pid 7408:tid 140286213650176] [client 213.81.157.70:52910] AH01797: client denied by server configuration: /var/www/nextcloud/config [Mon Jun 08 15:04:05.816081 2020] [access_compat:error] [pid 7408:tid 140285686302464] [client 46.34.234.215:15017] AH01797: client denied by server configuration: /var/www/nextcloud/config ```

Nextcloud log (data/nextcloud.log)

Nextcloud log

``` Log is empty after base cleaning, although the bug exists. ```

Browser log

Browser log

``` Browser log is not related, because bug exists only with webdav client. 3 clients have been tested. Before update was everything fine. ```

In the screenshot is Z: connected as WebDAV. File is copied, but show 0 size. In the oc_filecache there is also 0 in size field. Physically on the storage the file has proper size and content, but still show 0 in all clients. (webdav, mobile app, web interface) The same problem is with bigger files newly uploaded.

[biware-repo]

No solution for relative primitive bug? Before was all ok. Now if file is copied via Webdav there 0 size, although on the physical storage on nextcloud is ok. It is very strange and critical to use in real world.

[hwangjunjie]

I have the same problem -_-

[hwangjunjie]

I want to know from which version the problem started

[biware-repo]

For me after update to 19.0.0

[hwangjunjie]

I have downgraded to 18.0.6，it is fine

[biware-repo]

How did you do it. Generally it is not supported. Probably i need to do the same. But I do not know how.

[SilentMiner2]

I have downgraded to 18.0.6，it is fine

how did you downgrade? or did you restore a backup?

[TorinKR]

At the moment I found two solutions. The first is to use Air Live Drive as a mapping tool https://www.airlivedrive.com/en/ looks like it is working properly. Tests since last night and probably (?) No problems. The second solution that I started to research on the second test server yesterday is Nextcloud's night build. It also looks like it solves a problem!

[hwangjunjie]

I have downgraded to 18.0.6，it is fine

how did you downgrade? or did you restore a backup?

I reinstalled and copied th data directory, then create the top-level directory on site, and the data will be restored

[hwangjunjie]

I have downgraded to 18.0.6，it is fine

how did you downgrade? or did you restore a backup?

I reinstalled and copied th data directory, then create the top-level directory on site, and the data will be restored

@biware-repo you can try it

[bbolokofsky]

Same issue.
I noticed also that collabora office development Edition is sometimes zeroing out the file as well when opening an existing normal file and saving it. Even after the file is zeroed out CODE will still open the file and if I change it again sometimes it saves normally and sometimes it's still zero. Is there some way to get the nightly build for a docker install?

[wbonis]

Yes we see the same problem here!

Webdav (and Collabora) creates 0 byte files in the view. The content is still there.

Serious Bug, Because it can lead to data corruption, if a client saves back the 0 byte file, the data is lost.

Any ETA on a bugfix?

[bbolokofsky]

I was really hoping to see some kind of update on this. This seems to be a critical issue and has caused data loss for some of my clients. Data loss does not look good for us or Nextcloud. Unfortunately these were new installs and not upgrades so we can’t even restore from backup. We would just like to know if a fix is coming soon so we can decide weather we need to build new server installs and migrate the data (hundreds of thousands of files) for each of these customers or wait.

[julieni]

Hi,

I have some similar issue, mostly repeatable when working on a folder that is shared by an other user.

• create an XLSX file locally
• upload to Nextcloud shared folder with webdav client (tried Nautilus on linux and Cyberduck on Windows)
• try to open file from Nautilus: works
• edit file remotly in libre office OR change file locally with Excel in windows then reupload with cyberduck
• try to open file from Nautilus again: file is corrupted most of the time

NB: I'm not doing concurrent updates/uploads, but tested on 2 platforms

NB: It seems far less repeatable if my nextcloud user owns the folder the files are in (not a folder shared by another user)

Also tried with TXT files, with text editors or simply echoing some content to file from shell, also managed to have partial content over time, and even I/O errors in shell.

[stephenitpro]

Same problem using a webdav client (RaiDrive) for NC19 (LEMP on CentOS 8). Uploads the files fine but reports back on the Webdav mount and web ui as 0KB. Kinda dangerous.

[wbonis]

Yes, i also dont understand!

The Slogan is "A safe home for all your data" But this Bug in a released version of the Software is now more than 20days open! Exposing dataloss!

Everyone could loose data!

Why did now one of the core team even comment here?

Why is there no fix?

[stephenitpro]

This is true, NC19 is destroying people's data and wasn't ready for release. 👎

[bbolokofsky]

I’m curious is this only happening on Docker installs?

[stephenitpro]

My install is on bare metal and does odd things with webdav and webui uploads

[kesselb]

Please avoid "I have the same problem" and other unrelated comments. Such comments makes it harder to find the important information how to reproduce a problem. Use reactions to agree or disagree.

I tried to reproduce the upload a file via webdav problem with https://try.nextcloud.com but that seems to work with Nautilus:

1. Create a demo user A
2. Connect the user webdav with Nautilus 3.34.1
3. Copy a file to mounted folder - validate file size via terminal / remounted folder and web ui - seems correct (at least it's not 0kb)
4. Create another demo user B
5. B: Create a new folder and share it with user A
6. A: Copy files to the folder shared from user B - validate size again - seems correct
7. B: Also check the size of the files uploaded by user A

For your information: The desktop and mobile clients provided by Nextcloud are also using the webdav interface to access the files.

To develop a fix we need a reliable way to reproduce this problem. It would help if some of you could try to reproduce it with https://try.nextcloud.com and provide the steps.

Thanks in advance :+1:

[wbonis]

What i have done:

create a Account on try.nextcloud.com

Setup a webdav mount from Finder on Mac: ( to https://demo1.nextcloud.com/remote.php/dav/files/XLRgxCMFjjf7paj7/ )

Drop a File in the Documents Folder

Result: The File size is 0 ( in Finder and in the Webinterface)

[wbonis]

I did another Test on this Webdav mount ( See Screenshoots )

[bbolokofsky]

The same results are produced when using mountain duck or the native windows WebDAV client. Air live drive and an rclone mapped drive in windows for some reason do not cause the 0 byte problem.

[jospoortvliet]

In the dolphin and Konqueror file managers on Linux I get an error that there is no free space when I try to copy in files. What does work is creating a new text file (2 bytes...) and editing it. Creating a new presentation (ods) also gives the error and I can't copy in a 2 byte (new) flat text file either.

This was using cloud.nextcloud.com, running Nextcloud 19.0.1RC1.

A bit of testing showed however the same issue with Nextcloud 18.0.6, so this isn't new. I guess the WebDAV implementation is sensitive and doesn't work well with some/many clients.

[Bables55]

Will a fix for this issue be available in time for the 19.0.1 stable release scheduled for this week?

[bjoernv]

I tested uploading a LibreOffice Impress file directly via LibreOffice and via Dophin/KDE.

Saving a LibreOffice Impress via LibreOffice works.

Copying an existing LibreOffice Impress file via Dolphin results in the following error: There is not enough space on the disk to write file:///tmp/xyz.odp. /tmp/xyz.odp is the source file, so free disk space (> 10 Gbyte) should not be a problem.

The server is Nextcloud 18.0.6.

[biware-repo]

So again.

1. Mount nextcloud via webdav (eg. Windows WebClient)
2. Copy some file to nextcloud. This results to 0 file size. BUT FILESIZE IS OK ON PHYSICAL NEXTCLOUD STORAGE. In DB is 0. Creating files is not OK. There is no info about files size before inserting to DB.
3. Copy the same file again and rewrite the existing file. This results to proper file size in DB. File already exists size is properly updated in DB.

It is connected to process of creating new file and handling the filesize during creation.

[julieni]

Hi @kesselb,

I managed to reproduce on try.nextcloud.com.

Both users are on demo1

1st user : cBjg4s4NK8DnRL3T 2nd user : EzGSma6tkWZ5PwJa

2nd user shares a folder named "shared", then creates some subfolders

1st user uses Nautilus 3.36.3 (latest archlinux) and uploads an .xlsx file created with Libreoffice.

The file opens fine locally (of course), and remotely (fine too). Local and remote files show same size:

$ ls -al nc-test* -rw-r--r-- 1 julien users 4873 13 juil. 10:34 nc-test.xlsx

$ ls -al shared/a\ subfolder/another\ one/ total 5 drwx------ 1 julien users 0 13 juil. 10:54 . drwx------ 1 julien users 0 13 juil. 10:54 .. -rwx------ 1 julien users 4873 13 juil. 10:54 nc-test.xlsx

Then user1 updates file locally, and uploads it remotely with Nautilus, replacing the original one.

Local file still opens fine with libreoffice, but remote file is corrupt (error message in french, telling the file is corrupted and asking for repair)

Before updating the file, i made a copy to keep the original one locally, so we can see the size is different :

$ ls -al nc-test* -rw-r--r-- 1 julien users 4873 13 juil. 10:34 nc-test-orig.xlsx -rw-r--r-- 1 julien users 5248 13 juil. 10:57 nc-test.xlsx

and on remote side, the old size is returned (same for the modification time), even after a long time wait :

$ date lun. 13 juil. 2020 11:12:26 CEST $ ls -al shared/a\ subfolder/another\ one/ total 5 drwx------ 1 julien users 0 13 juil. 10:58 . drwx------ 1 julien users 0 13 juil. 10:58 .. -rwx------ 1 julien users 4873 13 juil. 10:54 nc-test.xlsx

Then a connected as user2 with webdav, replaced the file once again, then file and modification date are OK

$ ls -al total 6 drwx------ 1 julien users 0 13 juil. 11:22 . drwx------ 1 julien users 0 13 juil. 11:22 .. -rwx------ 1 julien users 5248 13 juil. 11:22 nc-test.xlsx

then updated local file, uploaded again as user2, and size and time update accordingly.

$ ls -al total 6 drwx------ 1 julien users 0 13 juil. 11:24 . drwx------ 1 julien users 0 13 juil. 11:24 .. -rwx------ 1 julien users 5265 13 juil. 11:24 nc-test.xlsx

So my best guess is that it happens (wrong sizes) when working on a shared folder if you're not the owner of that folder. Because both size nor time update, I bet it's db-cached infos related, I mean updating as not the owner does not trigger info updates.

Julien

[julieni]

Hi @kesselb,

just tried again on try.nextcloud.com, 100% reproducible.

2 accounts on demo2 server user 2 shares a folder "shared" with user 1

Everything is fine with user 2 :

$ echo "123456789" > test.txt $ ls -al test.txt -rwx------ 1 julien users 10 16 juil. 15:29 test.txt

reduce file :

$ echo "1234" > test.txt $ ls -al test.txt -rwx------ 1 julien users 5 16 juil. 15:30 test.txt

increase file :

$ echo "1234567" > test.txt $ ls -al test.txt -rwx------ 1 julien users 8 16 juil. 15:31 test.txt

NB: I have the same ls -al test.txt results from user 1 shell (user 1 just does listing at this step)

Now I switch to user 1 shell:

$ ls -al test.txt -rwx------ 1 julien users 8 16 juil. 15:31 test.txt $ cat test.txt 1234567 $ echo "12" > test.txt $ ls -al test.txt -rwx------ 1 julien users 8 16 juil. 15:31 test.txt

size and time are not updated (neither from user 1 nor user 2 shells), even after minutes waiting

writing the file a second time triggers size and time updates:

$ echo "12" > test.txt $ ls -al test.txt -rwx------ 1 julien users 3 16 juil. 15:35 test.txt

increasing content leads to corrupted file:

$ echo "123456789" > test.txt $ ls -al test.txt -rwx------ 1 julien users 3 16 juil. 15:38 test.txt $ cat test.txt 123

The file is corrupted because only 3 bytes (wrong cached size) are retrieved. At this point, the file is still OK on server side storage In fact, it will be corrupt if I save/sync that truncated file back to the server.

Writing once again triggers size and time update, as previously said:

$ echo "123456789" > test.txt $ ls -al test.txt -rwx------ 1 julien users 10 16 juil. 15:39 test.txt

but what I did not saw before : time is wrong

so another write, and everything is OK (size and time)

$ date jeu. 16 juil. 2020 15:54:24 CEST $ echo "123456789" > test.txt $ ls -al test.txt -rwx------ 1 julien users 10 16 juil. 15:52 test.txt

I would like to look at the code, but if you could point me to the right classes where the thing might happen, it would be much time saving as I don't know about nextcloud architecture

[stephenitpro]

Does anyone know whether this problem persists with the new NC19.0.1 update? If so, we'll have to wait for a 19.0.2 release on August 27th or hopefully a patch to fix the oc_filecache before then. Running a daily full scan takes too long and still has the high potential to corrupt sync client.

[Bables55]

Maybe that's different from this issue. In my case, it was worse than NC 19.0.0. The probability of office files being corrupted and unable to be opened has been greatly increased. WebDAV in NC19 is very dangerous.

[stephenitpro]

Maybe that's different from this issue. In my case, it was worse than NC 19.0.0. The probability of office files being corrupted and unable to be opened has been greatly increased. WebDAV in NC19 is very dangerous.

You upgraded to 19.0.1?

[bbolokofsky]

After upgrading one of our installs from 19.0 to 19.01. It seems to have solved the problem for at least mountain duck, windows WebDAV and Collabora. We will be doing more extensive testing over the next few days.

[stephenitpro]

After upgrading one of our installs from 19.0 to 19.01. It seems to have solved the problem for at least mountain duck, windows WebDAV and Collabora. We will be doing more extensive testing over the next few days.

Are you running it as a Docker container or on a bare host? I am watching the issues closely before I upgrade our NC19 instance which requires a lot of fine tuning for Nginx, Mariadb, and php-fpm. We are using Raidrrive as our freeware webdav Win 7/10 client but I too need to test Mountain Duck for MacOS clients.

[theoneandonly-vector]

is this the same issue?: https://github.com/nextcloud/server/issues/3056

[stephenitpro]

is this the same issue?:

3056

Seems like it but really hard to know 100% due to the varying types of installations available.

[biware-repo]

is this the same issue?:

3056

It is not the same. At the beginning of this, is written, files on physical storage have proper size. The problem is in updating of database where oc_filecache has 0 in field named size.

[julieni]

Will 19.0.1 be used on try.nextcloud.com ? If yes, when is it excepted. I'll try the same tests to see if files are still getting corrupted due to wrong size being cached

[stephenitpro]

So far I'm seeing better webdav results from my clients Mountain Duck (MacOS) and Raidrive (Windows) now that I applied NC19.0.01 update.

[julieni]

Hi,

is try.nextcloud.com updated to 19.0.1 ? it seems file's size / time reported via webdav are Ok now.

$ echo "123" > test.txt $ ls -al test.txt -rwx------ 1 julien users 4 22 juil. 17:41 test.txt

$ echo "123456" > test.txt $ ls -al test.txt -rwx------ 1 julien users 7 22 juil. 17:43 test.txt

$ echo "1234" > test.txt $ ls -al test.txt -rwx------ 1 julien users 5 22 juil. 17:46 test.txt

Will try to update my own instances to check.

EDIT: updated to 19.0.1, seems OK after first tests

Julien

[theoneandonly-vector]

I installed the update on 2 Instances and it fixed the issue on both.

[theoneandonly-vector]

I got another problem after the update, which might be related to the fix. (This happens only for .mkv files as of now) also not for all of them but for many. they will report a negative amount of bytes used and can't be played anymore. the size on disk is correct, but not so on web or webdav-client. scanning the files usign nextcloud.occ files:scan --all and renaming on disk won't result in any change.

As I switched OS on the machine Debian -> Ubuntu I now don't have this error anymore. I also tried to replicate this inside a Debian VM but am not able to do this anymore.

so for me it's fixed.

[solracsf]

Everyone: can you confirm the 19.0.1 release fix this? From my side, i can't reproduce it, either using Cyberduck or Raidrive.

React with 👍 for WORKS React with 👎 for DOESN'T WORK

If it doesn't work for you, please detail your test method (software used and versions).

[deajan]

Doesn't work for me with 19.0.2, see https://github.com/photoprism/photoprism/issues/443

[mahibi]

Doesn't work for me with 19.0.2 either. See https://github.com/laurent22/joplin/issues/3350#issuecomment-691494783 for details.

[JBM888]

I also have problems with WebDAV as well as the Windows 2.6.5 and 3.0.1 client. Files are either 0 bytes, very small (8 bytes) and a lot of file sync conflicts . Everything was fine until I let the system do an upgrade to NC19.... This needs to be addressed NOW!!! It's more or less a scandal that a version with these flaws was released. Claiming that one should sign up for support is NOT the way to handel such an issue that affect so many not to mention Nextclouds reputation. No one will consider a system so poorly maintained that clearly lack the stability for any serious business use. Development IS tricky business but serious bug(s) for this long? With "standard" installations like mine? That's not anything for any business use....

[ThisIsMe-TIM]

I use Joplin that worked fine until my upgrade to Nextcloud 19 ...

Here it is what I get (in french, my jopin is in french)

THe sync works fine (files are not empty) but not the "share notes" in my Joplin desktop or phone app

---

Impossible de se connecter à l'appli Joplin pour Nextcloud. Veuillez vérifier la configuration. L'erreur complète était :

POST shares: Could not find sync target ""

0 /var/www/html/test/apps/joplin/lib/Service/JoplinService.php(43): OCA\Joplin\Service\JoplinService->item()

1 /var/www/html/test/apps/joplin/lib/Controller/ApiSharesController.php(43): OCA\Joplin\Service\JoplinService->note()

2 /var/www/html/test/lib/private/AppFramework/Http/Dispatcher.php(170): OCA\Joplin\Controller\ApiSharesController->create()

3 /var/www/html/test/lib/private/AppFramework/Http/Dispatcher.php(100): OC\AppFramework\Http\Dispatcher->executeController()

4 /var/www/html/test/lib/private/AppFramework/App.php(137): OC\AppFramework\Http\Dispatcher->dispatch()

5 /var/www/html/test/lib/private/AppFramework/Routing/RouteActionHandler.php(47): OC\AppFramework\App::main()

6 [internal function]: OC\AppFramework\Routing\RouteActionHandler->__invoke()

7 /var/www/html/test/lib/private/Route/Router.php(297): call_user_func()

8 /var/www/html/test/lib/base.php(1012): OC\Route\Router->match()

9 /var/www/html/test/index.php(37): OC::handleRequest()

10 {main} (404)

[PVince81]

as far as I can see, the Sabre DAV library (which Nextcloud uses) was supposed to block such uploads with an error instead of letting it go through with 0 bytes: https://github.com/sabre-io/dav/blob/master/lib/DAV/CorePlugin.php#L471

from reading this it seems there is no solution to make it work apart from switching clients or web server, but not sure what web server (or web server settings) would make it work

I've found this article from one of the Sabre DAV authors: https://evertpot.com/260/ So there might be server setups in which it can work.

[osscombat]

In my case the same problem using Mountain Duck was caused by the following nginx reverse proxy (NC 19.0.5 was behind it) settings

proxy_buffering off;
proxy_request_buffering off;

just removed them, and the problem gone.

[deajan]

The solution @osscombat provides works for nginx. For Apache, there's so such option and I had to switch back from php-fpm to mod_php in order to get this resolved ;(