Webdav linux client gvfs broken with nextcloud 15 and 17

đź’» Development
1

Hello,

I just had to find out that nextcloud webdav does not reliably work for linux clients using gvfs (1.42.2). I have no reason why, but can point to this:

It basically tells my problem. Libreoffice using a webdav share hangs and files do not get written.
Has anyone found a solution for this?

Regards

2

Use a app password for mounting the dav share instead of your password.

3

And where is the solution to the described problem? The password is not the problem. The problem is that gvfs is broken-by-design regarding webdav.

4

Due to the fact that this is not a Nextcloud problem, because WebDAV as it works as expected, I would contact the Nautilus developers and ask them to fix the issue :wink:

5

Be sure that I did this (with xfce/thunar) but the thing is that it is not a single file manager or application problem. In fact GVFS (the base of webdav on linux GUIs) is the problem. Which means no single linux desktop environment on the planet can work reliably with nextcloud as webdav file service. And I think this is a point to know at nextcloud…

6

Have you tested it? :wink:

I’ve looked into gvfs a while ago. It does not send cookies (like davfs2). That’s fine because dav is usually stateless. Nextcloud requires cookies to work. It works more reliable for me when using app passwords.

7

I have tested it, and believe me, there’s a lot wrong with current webdav handling in gvfs-using tools. I guess the true reason why not more people are seeing the problems is that they are possibly race conditions. If you are using a mostly sleeping pc you likely will not see troubles. If you try the very same things on virtualised environment chances are a lot better gvfs has severe problems.
The tools (like file managers) are pretty much the same. Take Thunar as an example. It looks good and seems to work with reasonable speed. But entering a folder mounted with davfs2 it takes around 28 seconds on my environment to show it, whereas in a bash using “ls -l” you get the output immediately. So davfs2 works as expected, whereas Thunar seems broken as well. I talked to the author and he obviously has not the slightest idea what is going on. All implemented switches regarding thumbnails and the like make no difference in terms of time.
Mounting with gvfs btw shows exactly the same problems (ridiculous speed).