Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot upload files using webdav extension. #3628

Closed
abpostelnicu opened this issue Feb 26, 2017 · 42 comments
Closed

Cannot upload files using webdav extension. #3628

abpostelnicu opened this issue Feb 26, 2017 · 42 comments
Labels
1. to develop Accepted and waiting to be taken care of bug feature: dav

Comments

@abpostelnicu
Copy link

Hello,

I've installed recently nexcloud, and i'm trying to upload files using the webdav extension. But it fails with the message:
screen shot 2017-02-26 at 10 22 25
Although the upload fails it still creates the file on the webdav server but with a length of 0 bytes.

The server error log that i get is:

Sabre\DAV\Exception: HTTP/1.1 500 No subsystem set a valid HTTP status code. Something must have interrupted the request without providing further detail.
/media/588c3a53-edd3-4f27-bcc1-7d2281ed8aec/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php - line 254: Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
/media/588c3a53-edd3-4f27-bcc1-7d2281ed8aec/www/nextcloud/apps/dav/appinfo/v1/webdav.php - line 60: Sabre\DAV\Server->exec()
/media/588c3a53-edd3-4f27-bcc1-7d2281ed8aec/www/nextcloud/remote.php - line 165: require_once('/media/588c3a53...')
{main}

The configuration of my server is as follows:

OS: Debian 8
Web Server: Nginx 1.6.2
PHP-FPM: 5.6.30-0+deb8u1
MySQL: 5.6.35

Any advise is well appreciated.

@Domoel
Copy link

Domoel commented Feb 28, 2017

I have the same problem.

@nickvergessen
Copy link
Member

Can you please have a look at the access log of your server with the same timestamp and check what page was requested with which user agent?
Like in #2887 (comment)

@abpostelnicu
Copy link
Author

abpostelnicu commented Mar 8, 2017

Here are the logs, for example i'm trying to copy and paste Test2.cpp, the output is:

"PROPFIND /remote.php/webdav/.Test2.cpp HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/.
. HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/Test2.cpp HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/ HTTP/1.1" 207 5692 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._.DS_Store HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Home%20Assistant HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Apps HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Documents HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Downloads HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Home%20Clips HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Movies HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Music HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Photos HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Projects HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/.TV%20Shows HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/ HTTP/1.1" 207 5692 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/Test2.cpp HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PUT /remote.php/webdav/Test2.cpp HTTP/1.1" 201 0 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/.Test2.cpp HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"LOCK /remote.php/webdav/Test2.cpp HTTP/1.1" 500 315 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/.
. HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/Test2.cpp HTTP/1.1" 207 624 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/Test2.cpp HTTP/1.1" 207 624 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/ HTTP/1.1" 207 6132 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/.
.DS_Store HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Home%20Assistant HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Test2.cpp HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Apps HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Documents HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Downloads HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Home%20Clips HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Movies HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Music HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Photos HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._Projects HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/._TV%20Shows HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"

No logs are present in the nginx error log

@nickvergessen
Copy link
Member

@abpostelnicu
Copy link
Author

Unfortunately the result is the same:

"PROPFIND /remote.php/webdav/Apps/clang-format-test.cpp HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/Apps/clang-format-test.cpp HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PUT /remote.php/webdav/Apps/clang-format-test.cpp HTTP/1.1" 201 0 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"PROPFIND /remote.php/webdav/Apps/._clang-format-test.cpp HTTP/1.1" 404 11562 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"
"LOCK /remote.php/webdav/Apps/clang-format-test.cpp HTTP/1.1" 500 315 "-" "WebDAVFS/3.0.0 (03008000) Darwin/16.4.0 (x86_64)"

A 0 byte file is created.

@vivorbv
Copy link

vivorbv commented Mar 15, 2017

Exactly the same here. Tested with Apache 2.4 + PHP 7.0 and nginx + PHP 7.0 and nginx + PHP 7.1. After applying the patch from #3757 I don't get the "can't be read or written" error anymore, but file uploads result in extremely long waiting times (+60s for a 10KB file) and eventually fail (after the 60s+ wait a 0KB file is created).

@DanClarke-io
Copy link

Just to add to this, I am getting the same issue as @vivorbv, does transfer, but takes over a minute to do 200kb.

@Yamakasi
Copy link

I see the same issue at the moment, I hope we can this fixed as I finally have webdav mounted again :)

@JonathanSchndr
Copy link

What is the status? @nickvergessen

@Yamakasi
Copy link

I can mount WebDav using NET USE but can indeed not upload using it.

@paolomeraviglia
Copy link

problem mounting webdav with OSX and windows only: What is the status? How can I solve this?

@vivorbv
Copy link

vivorbv commented Apr 11, 2017

Is there any news on this? It's been almost a month and this issue heavily affects what we regard as the core of nextcloud's functionality (file storage). Is it possible to give this issue a higher priority?

@paolomeraviglia
Copy link

news about this problem?

@LLynx
Copy link

LLynx commented May 4, 2017

After updating to „Nextcloud 11.0.3 (stable)“ there were no error messages anymore (Goodbye to „Error code -36“). Nevertheless I still can't upload any files via OSX Finder to a mounted „nextCloud“ folder ;-( Just mentioned not to forget this ... well ... not insignificant little slutty bug.

@abpostelnicu
Copy link
Author

I can confirm that updating to 11.0.3 fixed the issue on macOS.

@LLynx
Copy link

LLynx commented May 5, 2017

Dear abpostelnicu, 11.0.3 does NOT fixed the problem: Still UNABLE to upload files via OSX Finder to a mounted „nextCloud“ folder. Just to be sure this thread should stay open.

@skitter-anton
Copy link

Is there any update on this? I just did a complete clean install and experience the same problems on OSX (Sierra).

@JonathanSchndr
Copy link

Solved: Delete Nextcloud.

@skitter-anton
Copy link

@JonathanSchndr , I don't understand. You mean from the client? I checked and indeed had Nextcloud app installed on the client. I stopped the process, deleted the app, restarted and tried again. I get the same error (0kb files).

@JonathanSchndr
Copy link

JonathanSchndr commented Jul 17, 2017

@skitter-anton No, sorry. iam frustrated about the missing support and patches.. i deleted nextcloud completely and use another solution.

@skitter-anton
Copy link

@JonathanSchndr Ah :-) Thank you for your reply. Any way you want to share your solution?

@DanClarke-io
Copy link

Hi there,

I've just tested this on macOS 10.12.5 and Nextcloud 11.0.3 and it uploaded very quickly, see attached.
Untitled.mov.zip

@skitter-anton
Copy link

I am using Nextcloud version 12.0.0. I also have OSX Sierra 10.12.5 installed.

@JonathanSchndr
Copy link

@OverByThere Not working :/
@skitter-anton Yes, Dropbox. :P

@tflidd
Copy link
Contributor

tflidd commented Jul 19, 2017

@nickvergessen Are there still infos missing? Quite a few people are interested, so it would be great to tag if it is considered as a bug or feature enhancement ;-)

@Schmuuu
Copy link

Schmuuu commented Jul 19, 2017

So far everything else works normal, or are general downloads slow as well?

I read about the "TCP window scaling problem" recently and thought it is maybe worth looking into that, while it seems hard to find a solution currently:
https://wiki.archlinux.org/index.php/Network_configuration#The_TCP_window_scaling_problem
(see the part "How to diagnose the problem")

Especially when older OS are used, this could still be a problem today I guess.

@okoeroo
Copy link

okoeroo commented Sep 2, 2017

Hi, I've read all similar issues related to WebDAV usage and the -36 error from Finder.app (macOS). I have applied the two available patches, both are non-functional. Are there any developers with macOS available to fix it? This problem seem to linger since February without a resolution.

@MorrisJobke
Copy link
Member

ref #4197

@MorrisJobke
Copy link
Member

ref #6152

@okoeroo
Copy link

okoeroo commented Sep 8, 2017

Ok, so we've cross linked all the similar bugs on WebDAV's functionality in multiple versions. The problem seems to be pretty persistent as it seems to emerge in 11.x and is now also in 12.x. As I see it the Sabre DAV part is acting up. Sabre seems to have implemented the proper sequences for file locking. In the code I see fake locks, perhaps the Sabre 3rd party code requires updating.

@carlu93
Copy link

carlu93 commented Nov 23, 2017

I'm having a similar problem. Uploading files via Windows Explorer Share works as expected. Files get created with the expected filesize. Using Mountainduck or Expandrive for Windows results in 0 byte files. Nothing is logged unfortunately. Is there any fix in the pipeline? Thanks guys!

@ylangisc
Copy link

ref #7995

@dnwk
Copy link

dnwk commented Feb 9, 2018

I have similar problem that I can't upload using webdav. I am using S3 as primary storage and I am on NextCloud 13!
Here are logs.
Sabre\DAV\Exception: An exception occurred while completing a multipart upload: Error executing "CompleteMultipartUpload" on "https://nyc3.digitaloceanspaces.com/{reducted}?uploadId=2~Zooq{reducted}NVYqo6ladIlk3oK"; AWS HTTP error: Client error response [url] https://nyc3.digitaloceanspaces.com/{reducted}?uploadId=2~Zooq{reducted}NVYqo6ladIlk3oK [status code] 400 [reason phrase] Bad Request MalformedXML (client): - MalformedXML{reducted}tx00000000000000005d8d8-005a7e2a6b-106ed5-nyc3a106ed5-nyc3a-nyc
/var/www/html/apps/dav/lib/Connector/Sabre/File.php - line 186: OCA\DAV\Connector\Sabre\File->convertToSabreException(Object(Aws\S3\Exception\S3MultipartUploadException))
/var/www/html/apps/dav/lib/Connector/Sabre/Directory.php - line 151: OCA\DAV\Connector\Sabre\File->put(Resource id #8)
/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php - line 1096: OCA\DAV\Connector\Sabre\Directory->createFile('chandleroleary_...', Resource id #8)
/var/www/html/3rdparty/sabre/dav/lib/DAV/CorePlugin.php - line 525: Sabre\DAV\Server->createFile('files/dnwk/imag...', Resource id #8, NULL)
[internal function] Sabre\DAV\CorePlugin->httpPut(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
/var/www/html/3rdparty/sabre/event/lib/EventEmitterTrait.php - line 105: call_user_func_array(Array, Array)
/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php - line 479: Sabre\Event\EventEmitter->emit('method PUT', Array)
/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php - line 254: Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
/var/www/html/apps/dav/lib/Server.php - line 283: Sabre\DAV\Server->exec()
/var/www/html/apps/dav/appinfo/v2/remote.php - line 35: OCA\DAV\Server->exec()
/var/www/html/remote.php - line 164: require_once('/var/www/html/a...')
{main}

@nextcloud-bot nextcloud-bot added the stale Ticket or PR with no recent activity label Jun 20, 2018
@jamierocks
Copy link

I have the same issue running 13.0.4. :(

@nextcloud-bot nextcloud-bot removed the stale Ticket or PR with no recent activity label Jul 11, 2018
@LLynx
Copy link

LLynx commented Jul 23, 2018

Careful reason for bright joy: I think they finally made it!

I just had 13.0.5. installed and – it worked: Since the beginnings of the old "owncloud" versions I was just able to conjure a file directly from the macOS Finder into the Nextcloud for the first time!

Simply drag and drop from a (local) folder to a (remote) folder!

21st Century: We are coming! ;-)

THX guys!

macOS High Sierra
Version 10.13.6

@jamierocks
Copy link

I'll update and give it a go, hoping it works :D

@LLynx
Copy link

LLynx commented Jul 23, 2018

Bad news. I was too euphoric. They did NOT make it ;-( ... only continue that zero byte file thing.

A small consolation: What I can faithfully reproduce is this:

When I look at a local file in a browser (file: //), I can drag and drop the file from the browser window to a (remote) folder. Then the file arrives in Nextcloud.

Strange, but go. Is this that "locking thing"?

@steffen-moser
Copy link

I run into the same problem with Apple's Finder (macOS High Sierra 10.13.6) as a WebDav client and the following Nextcloud installation:

Nextcloud: 13.0.5
Server OS: Oracle Solaris 11.3 SRU 34 (11.3.34.4.0)
Web Server: Apache 2.4.33
PHP-FPM: 7.1.17
MySQL: 5.7.17

The problem only occurs when using PHP-FPM. When switching back to "mod_php7", it is gone. I'm am very sure that the problem is documented here in the section "Chunked encoding". There is also an Apache bug which seems to be related to this one. For this moment, the only work-around, which seems to help, is to use mod_php instead of FPM...

@skjnldsv skjnldsv added the 0. Needs triage Pending check for reproducibility or if it fits our roadmap label Jun 12, 2019
@magnetic5355
Copy link

Having this issue - running a file:scan corrects the files however this is causing our organizations rollout of Next to fail since all of our mount drives report 0KB files until rescanned. Also modifying files in the GUI / openoffice does not update the file meta data causing files not to open via webdav until file:scan is rerun.

@okoeroo
Copy link

okoeroo commented Jul 8, 2020

This is the most silly bug ever. It's ultimately a problem in an underlying library implementing DAV and how it handles the locking mechanism. But both Owncloud and Nextcloud don't seem to be interested to apply sufficient support for over 3 years. If you intend to use Nextcloud from Finder mounts I would not consider this product for it. What could be done, assuming deployment fits other criteria on how you deal with the accounts, is to integrate a normal Samba tool that looks at the same user database, for example LDAP and have Nextcloud to look at that LDAP too. This bypasses this issue as you skip the WebDAV option and shift to CIFS/SMB on the same storage block.

@skjnldsv skjnldsv added 1. to develop Accepted and waiting to be taken care of and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Aug 20, 2020
@deadmanIsARabbit
Copy link

deadmanIsARabbit commented Dec 22, 2020

I ran into this issue as well.
Turns out nginx + php-fpm over a socket file is the main cause of this issue.
After switching from socket to an IP connection everything works as expected.
Props and thanks goes to @Temesta:
https://central.owncloud.org/t/nginx-connection-refused-for-webdav-requests-from-osx-client-app/17432/7

Can anybody confirm workaround as a solution for Apache aswell?

@skjnldsv
Copy link
Member

Well done @deadmanIsARabbit
Yeah, we're all relying on a very popular dav backend implementation.
It all works fine on the recommended setups we test against (see docs)

Closing then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of bug feature: dav
Projects
None yet
Development

No branches or pull requests