Server: Unable to use WebDAV connection to OVH shared hosting install.

[hameau]

Steps to reproduce

1. Upgrade from ownCloud or install clean on OVH shared hosting (pro2014)
2. Make adjustments to config.php & root .htaccess to minimise NC admin errors
3. Attempt to connect, via WebDAV (from any client, on a Linux or Windows workstation)
   

   Expected behaviour

Nextcloud files are browsable, etc. from within the client operating system

Actual behaviour

• Debian Linux xfce (Thunar/gvfs): error message: Failed to open "dav". HTTP Error: Service Unavailable. LibreOffice silently fails to connect to WebDAV server.
• Windows 7: silently fails to map network drive; LibreOffice silently fails to connect to WebDAV server.

This is a regression from ownCloud 8.2.5 (previously installed) and a regression from ownCloud 9.0.2 (clean install).

All other functions appear to work correctly from the web interface (file upload, download, share, ...) and using the desktop sync client (oC client v2.2.2).

Server configuration

Operating system:
Linux (kernel: 3.14.60)

Web server:
Apache 2.2

Database:
MySQL 5.5

PHP version:
PHP 5.6.21

Nextcloud version: (see Nextcloud admin page)
9.0.51

Updated from an older Nextcloud/ownCloud or fresh install:
The same symptoms for an upgrade from oC 8.2.5 and a clean install of NC 9.0.51

Where did you install Nextcloud from:
Nextcloud web site, server download

Signing status (Nextcloud 9.0 and above):
'No errors have ' (sic)

List of activated apps:

No apps activated beyond basic install

The content of config/config.php:

<?php
$CONFIG = array (
  'passwordsalt' => 'XXXX',
  'datadirectory' => 'XXXX',
  'dbtype' => 'mysql',
  'version' => '9.0.51.0',
  'installed' => true,
  'instanceid' => 'XXXX',
  'loglevel' => 0,
  'theme' => '',
  'dbname' => 'XXXX',
  'dbhost' => 'XXXX',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'XXXX',
  'dbpassword' => 'XXXX',
  'maintenance' => false,
  'trusted_domains' => 
  array (
    0 => 'cloud.XXXX.com',
  ),
  'secret' => 'XXXX',
  'trashbin_retention_obligation' => 'auto',
  'memcache.local' => '\\OC\\Memcache\\ArrayCache',
);

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

Are you using encryption: No

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

Logs

Web server error log

No webserver errors

Web server access log

"OPTIONS /remote.php/webdav HTTP/1.1" 503 26 "-" "gvfs/1.22.2"
and
"PROPFIND /remote.php/webdav:443 HTTP/1.1" 503 - "-" "LibreOffice" "HEAD /remote.php/webdav:443 HTTP/1.1" 503 - "-" "LibreOffice"

Nextcloud log (data/owncloud.log)

No Nextcloud errors

[LukasReschke]

Can you provide an unencrypted traffic dump of what your clients are sending as well as the server response?

[hameau]

unencrypted traffic dump

Attached to mail at your profile address.

[voidzero]

I am getting a 503 on my self-hosted nextcloud using nginx and php-fpm, when TotalCommander (android client) is trying to connect. This is a migrated owncloud 9.0.3 installation, used to work there.

[ksmolder]

I am also running nextcloud on a self-hosted server. When trying to mount my webdav share with OSX Finder, the mounting fails. The OSX log files contains the following lines:

webdavfs_agent: unexpected statusCode 503
webdavfs_agent: network_mount: network_getDAVLevel returned error 2

[voidzero]

For me, Totalcmd published an update that fixed my problem. Apparently it had something to do with cookies.

[ochurlaud]

Any news on that?

[voidzero]

On what? Totalcommander or the bug?

[ochurlaud]

On the bug. @LukasReschke didn't answer and the label is still "needs info"

[hameau]

I am the original reporter; I have heard nothing more.

I have since moved back to ownCloud.

[ksmolder]

@LukasReschke Is there anything we can do to provide you with additional information? WebDAV functionality seems really broken on some installations which limits the functionality of nextcloud in a harsh way.
As @hameau, reverting back to Owncloud seems the only viable solution after more than a month...

[LukasReschke]

Looking at the traffic dump. The problem is pretty certainly fixed in at least 9.0.53. The trace performs an OPTIONS request to /remote.php/dav/ and gets a 503 back. In current versions this works properly:

➜  ~ curl -v http://10.211.55.7/stable9/remote.php/dav  -u admin -X OPTIONS|pbcopy
Enter host password for user 'admin':
*   Trying 10.211.55.7...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 10.211.55.7 (10.211.55.7) port 80 (#0)
* Server auth using Basic with user 'admin'
> OPTIONS /stable9/remote.php/dav HTTP/1.1
> Host: 10.211.55.7
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.49.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 09 Aug 2016 16:38:56 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Set-Cookie: ocob0vvxe3af=31fnqelhmbu50suffubcqtqni4; path=/stable9; HttpOnly
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Set-Cookie: oc_sessionPassphrase=mHt5PwC6ujNhPRs0y8Av7XESzf64hxZduY3LjdtDFnF2xEY9w%2BzrfsQ0lAOYhEXucoB4GpXHmx1ZAYeYxwWe23JGqHAHo2D8m6HGaszrRPBs8NUxXkljz9Eli7WBAkUW; path=/stable9; HttpOnly
< Content-Security-Policy: default-src 'none';
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: Sameorigin
< X-Robots-Tag: none
< X-Download-Options: noopen
< X-Permitted-Cross-Domain-Policies: none
< Set-Cookie: nc_sameSiteCookielax=true; path=/stable9; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< Set-Cookie: nc_sameSiteCookiestrict=true; path=/stable9; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< Set-Cookie: ocob0vvxe3af=7n9dv0djvf5toqb1m31l74fih7; path=/stable9; HttpOnly
< Set-Cookie: cookie_test=test; expires=Tue, 09-Aug-2016 17:38:57 GMT; Max-Age=3600
< Allow: OPTIONS, GET, HEAD, DELETE, PROPFIND, PUT, PROPPATCH, COPY, MOVE, REPORT
< DAV: 1, 3, extended-mkcol, access-control, calendarserver-principal-property-search, calendar-access, calendar-proxy, calendar-auto-schedule, calendarserver-subscribed, oc-resource-sharing, addressbook
< MS-Author-Via: DAV
< Accept-Ranges: bytes
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host 10.211.55.7 left intact

Has anybody an account on one affected instance for me that is running 9.0.53?

[ochurlaud]

Yes, me

[LukasReschke]

Proposed patch at https://github.com/nextcloud/server/pull/797. Testing welcome. Thanks a lot, @ochurlaud for helping debugging this.

[ochurlaud]

Just tested, it worked for me.

[ochurlaud]

The patch worked for me. I'm enjoying again nextcloud. Thx @LukasReschke for the time you spend to help me debugging and the quick fix you provided.

[jospoortvliet]

@LukasReschke continues his awesome streak.

[ochurlaud]

Still on the same topic... I realized that my Android was _not_ synchronized anymore (caldav, carddav). I tried with and without the patch. I tried DAVdroid, CardDAV-Sync free (Marten Gajda), CalDAV Sync Adapter... All returned 503 Errors.

Changing the function cookieCheckRequired() so that it always return false allow to synchronize again.
The cookie-stuff of OVH, is really fucking up everything...

[ksmolder]

Thanks for the update @LukasReschke. Will test this coming weekend when I'm back from vacation (currently on very limited internet access). - Kurt

---- Lukas Reschke wrote ----

Proposed patch at #797. Testing welcome. Thanks a lot, @ochurlaud for helping debugging this.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/nextcloud/server","title":"nextcloud/server","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/nextcloud/server"}},"updates":{"snippets":[{"icon":"PERSON","message":"@LukasReschke in #223: Proposed patch at https://github.com/nextcloud/server/pull/797. Testing welcome. Thanks a lot, @ochurlaud for helping debugging this."}],"action":{"name":"View Issue","url":"https://github.com/nextcloud/server/issues/223#issuecomment-238626440"}}}

[ksmolder]

The patch doesn't solve the problem with webdav on OSX; still getting the 503 error messages in the log and can't establish the webdav mount:

webdavfs_agent: unexpected statusCode 503
webdavfs_agent: network_mount: network_getDAVLevel returned error 2

I will try to collect an unencrypted network dump tomorrow.

[ksmolder]

@LukasReschke I've sent the tcpdump files to the email address mentioned in your profile. If any further assistance is needed, let me know.

[ochurlaud]

@LukasReschke: The OVH answer I got was "Our installation works with ownCloud: it seems that NextCloud does something wrong. If you don't want to be dependent from our installation, please consider upgrading to [more flexible and expensive solution]".

Now I disabled completely the cookie checking (see previous comment). But it cannot be right.

[Swiiney]

Hi,
Just test the patch on 10.0 released installed on OVH shared host.
Working great so fare. Not working without.

Thanks @LukasReschke

[ksmolder]

Helas, still not working after upgrading to Nextcloud 10, with or without the suggested patch doesn't make any difference.

Please let me know what is required from my part in order to debug this issue. Nextcloud is really broken as long as I cannot access its data via webdav in OSX.

I really appreciate all the effort you put in this nice peace of software, but I would like to see this resolved as not being able to connect to Nextcloud from OSX makes it much less useful for my users.

[ochurlaud]

@LukasReschke The patch didn't fix it at the end... Any way to debug further? I think OVH users are a non negligible part of your users.

[CATER-COM]

The patch solved the problem with the Nextcloud Android app but not for caldav and carddav on Android #797 .

[ochurlaud]

@nickvergessen why did you close this issue? It still doesn't work for @CATERBN , me, and others.

[ksmolder]

This just doesn't feel right. There have been multiple comments indicating *dav is not yet functioning properly. There is an active will to provide the developers with additional information but instead the issue is just closed...

My first impression about nextcloud was that it actually wanted to focus more on the community. The way how this issue has been handled so far however is not contributing to that impression.

So please let us know which additional information is required to find the root cause of the issue or how we can help to debug it.

[ochurlaud]

It seems that the way to have things moving is to write @jospoortvliet .

Also, it's holiday time...

[LukasReschke]

It seems that the way to have things moving is to write @jospoortvliet .

They way to have things moving is to wait like every other person out there and not randomly mention other people after a few hours. You don't motivate people to help you with that. And this issue is to be honest rather low on my priority list with all the 1000 other things to do.

And of course, every person thinks their bug is the most important one. 😉

@LukasReschke: The OVH answer I got was "Our installation works with ownCloud: it seems that NextCloud does something wrong. If you don't want to be dependent from our installation, please consider upgrading to [more flexible and expensive solution]".

Totally questionable answer since oC doesn't use Same-Site Cookies. But well, OVH. 🙈

If somebody wants to see some more progress on this I gotta need an OVH account to have the ability to directly execute PHP code on the machine to debug this further. Everything else is just guessing in the dark and won't help.

If somebody is willed to grant me such an account: [email protected] is where you should send credentials to.

[ochurlaud]

Sorry for that I was going to edit my answer because I felt it was not correct to write that. Apologies.

[rullzer]

@nickvergessen why did you close this issue? It still doesn't work for @CATERBN , me, and others.

It was closed automagically by github because #797 was merged.

[ochurlaud]

Discussion with @LukasReschke on IRC, IMO, a little more communication from the Nextcloud side would be appreciated even to say "We'll work on this, but later as it's not top priority, stay tuned".

I gave him access to an OVH account. Let's wait some time and see.

[tflidd]

Just coming from topic #1237. If I try the curl command from https://github.com/nextcloud/server/issues/223#issuecomment-238612573, I get status 200 as well with the patch #797 but the native webdav connection doesn't work either.

I plugged in Wireshark to capture the traffic and sent it to@LukasReschke per mail. Also test account. Hope you can reproduce it.

Btw on my OS X 10.9, I can connect to demo.owncloud.org but not to demo.nextcloud.com with native WebDAV.

[LukasReschke]

Please test https://github.com/nextcloud/server/pull/1328 in combination with https://github.com/nextcloud/server/pull/797 for any OS X related issues.

[ochurlaud]

See #1328: it still doesn't work on my setting. It's very strange! How can I help you debugging more? I sent you a private mail for more debugs

[LukasReschke]

See #1328: it still doesn't work on my setting. It's very strange! How can I help you debugging more? I sent you a private mail for more debugs

Well. Providing the infos asked in my mail would help for once…

• Korganizer: I don’t happen to have a KDE setup. Can you test to add a return false; at the function in https://github.com/nextcloud/server/pull/1328/files ? If that works then we would need to have the user agent and add it to the incompatible user agents as well. This should then make it work. If that makes it work: please comment in the ticket.

[ochurlaud]

@LukasReschke : Oups, sorry I forgot.

So if I add return false; to the beginning of private static function performSameSiteCookieProtection() (so that it always returns false), it works very well on Korganizer _and_ DAVDroid.

[olivierkeke]

Same problem for me on gnome 3.14 : webdav still doesn't work with #1328 but adding return false; to beginning of private static function performSameSiteCookieProtection() makes it work.

It works also after adding '\^gvfs\' to the incompatible user agents.

Carddav and Caldav work well on gnome with nextcloud 10.0 and #797.

[CATER-COM]

Hi,
@ochurlaud and @olivierkeke can you please give more explanations where to add return false; in the private static function performSameSiteCookieProtection(). If possible can you provide an extract of code before/after. Adding /^gvfs/ in the incompatible user agents also solve the problem with Gnome on my Ubuntu.

[olivierkeke]

@CATBERN : here are the steps I follow:

• apply patch #797 and #1328
• add '/^gvfs/', in the file lib/base.php after '/^WebDAVFS/', at line 517.

I attached my lib/base.php.

base.php.txt

[CATER-COM]

Thank's @olivierkeke
In your base.php the line return false; is commented. @ochurlaud said that's useful to connect to connect with DAVdroid ? Did you get contact and calendar sync with DAVdroid withe an other way.
I uncommented the line and update DAVdroid to the 1.3.1 the DAVdroid sync seem to work But I need to provide the full link URL. If I use an URL like https://server/remote.php/dav/ as suggested on DAVdroid website it's not able to discover the srevices and I get the error message "No caldav or carddav service found".

[CATER-COM]

Well Nextcloud is now able to sync with Android app, with DAVdroid, Gnome and thunderbird even on shared hosting like OVH. Thanks to all of you. I can now imagine to migrate our professional instance of Owncloud to Nextcloud ;-)

[ochurlaud]

@CATERBN I experienced the same as you for the URL.

I don't know if you can migrate when you have to uncomment the return false line.

[olivierkeke]

@CATERBN The commented return false; was my addition. I think adding '/^DAVx5/' in the incompatible user agents list is better than adding return false;. It seems to work with my DAVdroid.

@LukasReschke Must we create separate issues for each incompatible user agent ? Or will it be possible to add element in this list with config.php ?

[CATER-COM]

Finally I had to remove comment the return false line as I was not able to loggin with this line. I don't noticed it before because I was already logged in when I did the change. But yesterday evening it refused my identification. After removing the line all return good. So I'll try '/^DAVx5/' in the incompatible user agents list.

It's a good idea to get a parameter in config.php with a list of user agents that you can comment /uncomment, at least as a workaround.

Thanks !

[CATER-COM]

Nice ! Adding '/^DAVdroid/' in the incompatible user agents list make DAVdroid working with Nextcloud on OVH shared host.

[tflidd]

@CATERBN Can you submit a pull request?

[nickvergessen]

Hmm, DavDroid works on normal servers just fine. Instead of adding all clients, I think the solution should be to only add those in case of OHV?

[Bugsbane]

I think I may still be getting this issue (connecting to WebDAV via dolphin works, but by some other means such as one of my Android apps, it gives a 503). I'm also using Nginx and php-fpm (on a Debian Jessie base).

I tried switching fastcgi lines in the site's nginx conf as per https://github.com/nextcloud/server/issues/237#issuecomment-253009162 to no effect. I'm self hosted, so I don't think it's https://github.com/nextcloud/server/issues/223 nor is it from any Apple device so it isn't https://github.com/nextcloud/server/issues/1237 .

Would it help to file a new bug and/or provide credentials to a test account on my server (running NC 10.0.1) @lukasreskche?

[derjochenmueller]

Hi, I have the error with Windows 7 without any error message and with Webdav in IE 11..9600.18524 with
Service Unavailable
Technical details
Remote Address: x.x.x.x
Request ID: xxxxxHDrnZwP5v2xxxxx
Browser based using Login Page it work like a charm in IE,Chrome,Firefox and Webdav with WinSCP Client.
Would be interested in a fix for the webdav problem. Can provide logs etc. if necessary.
Could the problem be the memcache?

{"reqId":"xxx","remoteAddr":"x.y.z.x","app":"gallery","message":"Exception: {\"Exception\":\"RedisException\",\"Message\":\"Redis server went away\",\"Code\":0,$
{"reqId":"yyy","remoteAddr":"x.y.z.a","app":"gallery","message":"Exception: {\"Exception\":\"RedisException\",\"Message\":\"Redis server went away\",\"Code\":0,$
{"reqId":"zzz","remoteAddr":"x.y.z.a","app":"core","message":"Exception when running cache gc: Redis server went away","level":2,"time":"2016-11-17T16:48:29+00:$
{"reqId":"vvv","remoteAddr":"x.y.z.a","app":"webdav","message":"Exception: {\"Message\":\"HTTP\/1.1 503 RedisException: Redis server went away\",\"Exception\"$

[tflidd]

{"reqId":"xxx","remoteAddr":"x.y.z.x","app":"gallery","message":"Exception: {\"Exception\":\"RedisException\",\"Message\":\"Redis server went away\",\"Code\":0,$

this is unrelated to this topic. Start your redis server and if you have configuration problems rather use help.nextcloud.com.

[jospoortvliet]

@Bugsbane yeah, if you still have this with 11RC, please - file a new bug, this one is overloaded with different stuff.

[poVoq]

Still happens with NC12 and OVH hosting. Can't use DavDroid to sync calendars.

Anyway to change this without modifying core files? Thanks a lot!

[ochurlaud]

On every update I change the base.php as described above.

That's not the best but still working. OVH discarded my ticket, saying it was Nextcloud problem.

[poVoq]

Hmm, if it works with other CalDAV clients, maybe it is rather the specific DavDroid implementation? Sadly they don't seem to have a public issue tracker :(

[ochurlaud]

@poVoq: they use this [1] as a tracker, it seems.

[1] https://forums.bitfire.at/category/4/davdroid

[ochurlaud]

For the record, as DAVDroid is now called DAVx5, the config.php file should contain

'csrf.optout' =>
  array (
    0 => '/^WebDAVFS/',
    1 => '/^Microsoft-WebDAV-MiniRedir/',
    2 => '/^DAVx5/'
)

instead of

'csrf.optout' =>
  array (
    0 => '/^WebDAVFS/',
    1 => '/^Microsoft-WebDAV-MiniRedir/',
    2 => '/^DAVdroid/'
)

[olivierkeke]

@ochurlaud Thank you ! I didn't notice caldav and carddav sync weren't working anymore on my android phone. And I was still patching my lib/base.php on every update.