Cannot upload files using webdav extension. #3628
Comments
|
I have the same problem. |
|
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? |
|
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)" No logs are present in the nginx error log |
|
Can you try to make the first change of https://github.com/nextcloud/server/pull/3757/files#diff-3ff2701e44d19445918d5340e29e53a3 |
|
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)" A 0 byte file is created. |
|
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). |
|
Just to add to this, I am getting the same issue as @vivorbv, does transfer, but takes over a minute to do 200kb. |
|
I see the same issue at the moment, I hope we can this fixed as I finally have webdav mounted again :) |
|
What is the status? @nickvergessen |
|
I can mount WebDav using NET USE but can indeed not upload using it. |
|
problem mounting webdav with OSX and windows only: What is the status? How can I solve this? |
|
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? |
|
news about this problem? |
|
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. |
|
I can confirm that updating to 11.0.3 fixed the issue on macOS. |
|
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. |
|
Is there any update on this? I just did a complete clean install and experience the same problems on OSX (Sierra). |
|
Solved: Delete Nextcloud. |
|
@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). |
|
@skitter-anton No, sorry. iam frustrated about the missing support and patches.. i deleted nextcloud completely and use another solution. |
|
@JonathanSchndr Ah :-) Thank you for your reply. Any way you want to share your solution? |
|
Hi there, I've just tested this on macOS 10.12.5 and Nextcloud 11.0.3 and it uploaded very quickly, see attached. |
|
I am using Nextcloud version 12.0.0. I also have OSX Sierra 10.12.5 installed. |
|
@OverByThere Not working :/ |
|
@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 ;-) |
|
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: Especially when older OS are used, this could still be a problem today I guess. |
|
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. |
|
ref #4197 |
|
ref #6152 |
|
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. |
|
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! |
|
ref #7995 |
|
I have similar problem that I can't upload using webdav. I am using S3 as primary storage and I am on NextCloud 13! |
|
I have the same issue running 13.0.4. :( |
|
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 |
|
I'll update and give it a go, hoping it works :D |
|
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"? |
|
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 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
added
the
0. Needs triage
|
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. |
|
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
added
1. to develop
|
I ran into this issue as well. Can anybody confirm workaround as a solution for Apache aswell? |
|
Well done @deadmanIsARabbit Closing then. |
and others
Hello,
I've installed recently nexcloud, and i'm trying to upload files using the webdav extension. But it fails with the message:
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.
The text was updated successfully, but these errors were encountered: