WebDAV extremely slow

I noticed that too. I use webdav a lot for university, and it's extremely slow.
Windows and MacOSX are pretty fast though ;-)

Is this symptom still reproducible in 8.10 or 9.04?

this problem reproduced on 8.04, it is so slow.
but fast on windows

And also reproduced on 8.10

I can confirm it is extremely slow on 8.10. I can access my server extremely fast with a ftp connection, so I have given up on davfs2.

I confirm slow on 8.10. Access through Nautilus is unusable. Access from the command line is better, but unpredictable. It seems like ls on a dir with lots of subdirs is slow. Maybe some caching going on? WebDAV access to the same server with Windows is pretty snappy.

What further information do you need? This bug exists and still there in 8.10 and 9.04.

Nautilus got an extreme problem with webdav and davfs.
I automount my webdav-drives using davfs, and everything works as expected using a terminal and the bash. cd, ls and everything works like crawling through local folders.
Nautilus does not.
Even if I change the settings to 'never' show preview (which would make sense and I thought I solved the problem) does not make it better.

Does this problem appear in other linux-distributions?

Is there a way to use another file-system-browser instead of nautilus?

I tried thunar instead of nautilus - same problem, opening of folders with content is dead slow.

But, folks - try this:
apt-get install gnome-commander
and - if you have the same setup - open the mounted webdav-folder in your locale filesystem and everything works perfectly.
The commander is even the better filebrowser for me, I'd like to make it default on my Ubuntu Netbook Remix Hercules eCafe 900 Netbook - it suits perfectly my needs.

Hope this helps someone to get webdav usable with Ubuntu until nautilus/thunar get fixed.

I use 9.04. When i access the same account from windows it's a lot faster. In Ubuntu it takes ages just to navigate around.
Any help would be appreciated. I tried gnome-commander. A bit better but still nowhere near the Windows client.

Thanks..

The bug is still present in Karmic 9.10. Mounting a webdav share in command line works well but navigating in it is very slow (when using ls or autocompletion, and nautilus is almost unusable). Mounting the share directly in nautilus (the graphical way) improve things a lot (it's as fast as in windows) but I can't copy a folder (I get a html file in the destination).

davfs2 version : 1.4.1

I'm having the same behaviour here.

I'm on Jaunty 9.04 using davfs. I'm trying to synchronise a local folder with a folder on a webdav server (mounted with davfs) using rsync. It's too slow to be usable.

Thanks.

same Problem with ubuntu 9.10 and Konquerror or Dolphin

Wolfgang_Pfalzgraf schrieb:
> same Problem with ubuntu 9.10 and Konquerror or Dolphin
>
>
Hi Wolfgang.
It is very easy to get WebDAV run deadly fast, when using a
GUIfile-manager tool not providing features you run into trouble, cause
a WEBdavdrive doesn't have enough speed to support it.
Examples:
Thumbnails (all kind of pictures, PDF, videos) Sound- or Video preview
and so on...

The only solution I found so far (apart of the terminal of course) is
Gnome-Commander and it offers by far more features for data interchange
as the 'common' desktop file-somethings have...

Install it and I am shure you will be amazed how nice it is to have a
storage place in the web.
I like it very much and WEBdavdrives are fun 4 me now and nice to have...

Steffen

Same problem here on a Karmic installation.
When using it with Dolphin is quite fast but when mounting it using davfs2 is deadly slow!

I found a similar problem and filed it under Bug #540507. Now I found this.
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/540507
Seems familiar! But I see slightly different behaviour.

I found the same problem on Ubuntu 10.10: I use davfs via autofs and I am waiting minutes to get a directory listing back from an 'ls' command.

I've set LOGGING='debug' in /etc/default/autofs. I do 'service autofs restart'. Then I keep a 'live view' on /var/log/daemon.log: every 5 seconds autofs spits out some information about whether it should keep directories mounted. In another shell I then do an 'ls' on a directory that should be first mounted by autofs (via davfs). It tells that is has mounted the directory, right after I've executed the 'ls'. Then the shell waits for the 'ls' command to return a listing (for very long) and in the mean time the file daemon.log just keeps on adding the usual 'expire' messages. It DOES NOT show any more messages, even when the 'ls' finally comes back with the directory listing.

So, mounting is successful, but then ?

Here's a part of the daemon.log file:

Jan 12 13:18:00 my-laptop automount[15900]: attempting to mount entry /srv/dav/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: attempting to mount entry /srv/dav/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: lookup_mount: lookup(file): looking up somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: lookup_mount: lookup(file): somedavdir -> -fstype=davfs,rw,nodev,uid=1000,gid=1000#011https://webdavserver.com/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: parse_mount: parse(sun): expanded entry: -fstype=davfs,rw,nodev,uid=1000,gid=1000#011https://webdavserver.com/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: parse_mount: parse(sun): gathered options: fstype=davfs,rw,nodev,uid=1000,gid=1000
Jan 12 13:18:00 my-laptop automount[15900]: parse_mount: parse(sun): dequote("https://webdavserver.com/somedavdir") -> https://webdavserver.com/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: parse_mount: parse(sun): core of entry: options=fstype=davfs,rw,nodev,uid=1000,gid=1000, loc=https://webdavserver.com/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: sun_mount: parse(sun): mounting root /srv/dav, mountpoint somedavdir, what https://webdavserver.com/somedavdir, fstype davfs, options rw,nodev,uid=1000,gid=1000
Jan 12 13:18:00 my-laptop automount[15900]: do_mount: https://webdavserver.com/somedavdir /srv/dav/somedavdir type davfs options rw,nodev,uid=1000,gid=1000 using module generic
Jan 12 13:18:00 my-laptop automount[15900]: mount_mount: mount(generic): calling mkdir_path /srv/dav/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: mount_mount: mount(generic): calling mount -t davfs -s -o rw,nodev,uid=1000,gid=1000 https://webdavserver.com/somedavdir /srv/dav/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: mount(generic): mounted https://webdavserver.com/somedavdir type davfs on /srv/dav/somedavdir
Jan 12 13:18:00 my-laptop automount[15900]: dev_ioctl_send_ready: token = 88
Jan 12 13:18:00 my-laptop automount[15900]: mounted /srv/dav/somedavdir

---and then it keep on outputting these messages (which are not correlated to the problem, I think) ----

Jan 12 13:18:03 my-laptop automount[15900]: expire_cleanup: sigchld: exp 140092989744896 finished, switching from 2 to 1
Jan 12 13:18:04 my-laptop automount[1...

Further to #17: I've switched off the debug in autofs and set 'DEBUG most' in /etc/davfs2/davfs2.conf .

it seems to be not able to connect/find the server. With a windows machine or lftp I never experience any delay and with davfs it is nearly always there at the first attempt.

davfs outputs to /var/log/debug the following (while executing the 'ls' command as in #17):

Start of davfs:
Jan 12 13:18:00 my-laptop mount.davfs: davfs2 1.4.6
Jan 12 13:18:00 my-laptop mount.davfs: /sbin/mount.davfs https://webdavserver.com/somedavdir /srv/dav/somedavdir -o rw,nodev,uid=1000,gid=1000
Jan 12 13:39:44 my-laptop mount.davfs: davfs2 1.4.6
Jan 12 13:39:44 my-laptop mount.davfs: /sbin/mount.davfs https://webdavserver.com/somedavdir /srv/dav/somedavdir -o rw,nodev,uid=1000,gid=1000
Jan 12 13:39:44 my-laptop mount.davfs: Configuration:

Then, right after doing a 'ls' on an unmounted webdav directory:

Jan 12 13:42:10 my-laptop mount.davfs: SELECT: 1
Jan 12 13:42:10 my-laptop mount.davfs: FUSE_LOOKUP:
Jan 12 13:42:10 my-laptop mount.davfs: p 0x1ea48c0, tst
Jan 12 13:42:10 my-laptop mount.davfs: lookup /somedavdir/tst
Jan 12 13:42:10 my-laptop mount.davfs: Running pre_send hooks
Jan 12 13:42:10 my-laptop mount.davfs: Sending request headers:#012PROPFIND /somedavdir/tst/ HTTP/1.1#015#012User-Agent: davfs2/1.4.6 neon/0.29.3#015#012Connection: TE#015#012TE: trailers#015#012Host: webdavserver.com#015#012Depth: 1#015#012Content-Length: 286#015#012Content-Type: application/xml#015#012Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx#015#012#015
Jan 12 13:42:10 my-laptop mount.davfs: Sending request-line and headers:
Jan 12 13:42:10 my-laptop mount.davfs: Sending request body:
Jan 12 13:42:10 my-laptop mount.davfs: Request sent; retry is 1.
Jan 12 13:42:40 my-laptop mount.davfs: Aborted request (-2): Could not read status line

(note the 30seconds delay)
(so here it aborts, but it will do another attempt:)

Jan 12 13:42:40 my-laptop mount.davfs: sess: Closing connection.
Jan 12 13:42:40 my-laptop mount.davfs: sess: Connection closed.
Jan 12 13:42:40 my-laptop mount.davfs: Request ends, status 0 class 0xx, error line:#012Could not read status line: connection timed out
Jan 12 13:42:40 my-laptop mount.davfs: Running destroy hooks.
Jan 12 13:42:40 my-laptop mount.davfs: Request ends.
Jan 12 13:42:40 my-laptop mount.davfs: RET: Success
Jan 12 13:42:40 my-laptop mount.davfs: tidy: 0 of 35 nodes changed
Jan 12 13:42:40 my-laptop mount.davfs: cache-size: 0 MiBytes.
Jan 12 13:42:40 my-laptop mount.davfs: SELECT: 1
Jan 12 13:42:40 my-laptop mount.davfs: FUSE_LOOKUP:
Jan 12 13:42:40 my-laptop mount.davfs: p 0x1ea48c0, .Trash
Jan 12 13:42:40 my-laptop mount.davfs: lookup /somedavdir/.Trash
Jan 12 13:42:40 my-laptop mount.davfs: Running pre_send hooks
Jan 12 13:42:40 my-laptop mount.davfs: Sending request headers:#012PROPFIND /somedavdir/ HTTP/1.1#015#012User-Agent: davfs2/1.4.6 neon/0.29.3#015#012Connection: TE#015#012TE: trailers#015#012Host: webdavserver.com#015#012Depth: 1#015#012Content-Length: 286#015#012Content-Type: application/xml#015#012Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx#015#012#015
Jan 12 13:42:40 my-laptop mount.davfs: Sending request-line an...

Has there been any thought into looking into this?

I have watched the traffic when thunar (xfce file manager) is very slow on a webdav2 mount and gets a folder listing. It seems it doesn't just get the file listing and displays the files, it gets the file listing and downloads the files as well. Some directories could have MBs of files in the directory and will slow this process down.

I'm also interested in this Problem - it would make owncloud much more usable for me... :(

Same here for me.
This slow response developed gradually as the WebDAV folder was filled. This renderd my own cloud almost useless.

same issue here with Ubuntu 13.04 as well as Ubuntu 13.10. Would be happy to see finally a fix after all those years.

I, too, notice this because it hurts my access to owncloud.

yep problem is still there, i can't use Nautilus with OpenDrive's webdav too, it's to slow..

I am using Ubuntu 14.04 and it's VERY slow accessing T-Online cloud. I have T-Online DSL connection and it's very slow accessing the T-Online clouzd. So it can't be the connection. If I opne a folder, it talkes aboiut 8 seconds untill I see the content in Nautilus.
 I terminal it's about 2 secons to see the content.

I am using Linux Mint 17 and can report the same.
Tested with Owncloud and apache2 webdav.
While razor fast in the console, file managers like nemo, dolphin or thunar
take endless (aborted after a few minutes) to display a directory with for example ~430 entries.

Strange things I saw, while I restartet the apache server while it
was loading the directory:

 - nemo: suddenly, all entries are listed correctly
 - dolphin: shows entries instantly but then still stuck loading (no response on scroll or window resize)

Does davfs not correctly detect the end of the http response?

Same on Ubuntu 13.10, 14.04 and 14.10.
Not using Nautilus or any other general purpose GUI file browser (only MC/ls and GNOME dialogs sometimes), uplink is fast enough, but if you want to upload/download some files more than 10MB in size each everything becomes inresponsive.

For instance, if you mount to /path/point then «ls /path» will get stuck. For instance, I run BOINC client with homedir there, and I can't connect to it with [G]UI. This all is because davfs is very single-threaded.

It even doesn't use ¼ bandwidth, although it could do, for instance, 2 threads for upload, 2 for download, if necessary.
gui_optimize set to 1 — doesn't help (and not designed to help with this)
cache size set to handle 6GB which is quite enough to handle most of upload batches I fed it with.

How can we help with solving this?

I have discovered an issue with davfs2 that causes webDAV to be extremely slow, this is possibly related to the cause of this bug, although it could be a different issue, which is why I filed it as a seperate bug:
https://bugs.launchpad.net/ubuntu/+source/davfs2/+bug/1490555

Same in Ubuntu 16.04.

Accessing a Nextcloud 12 from kubuntu 16.04 (xenial) this is still a big problem. Access to files and folders is very slow.

I observed something interesting. I am running KDE, and both the konqueror (still running KDE 4) and dolphin (KDE plasma 5) file managers have their own webdav implementation, which is much faster. Just by putting "webdav://" into the address bar followed by the address, I can directly access the pages. And it is blazingly fast! I would say at least one order of magnitude faster than mounting the same server via davfs2 and accessing it this way.

The advantage of this test is that I can access the very same webdav server from the same machine in both ways. Therefore, I can rule out speed limitations on the server side, performance limitations on my machine, or network speed as reasons for the davfs2 slowness. However, while the "webdav://" implementation is good to browse files, it is not a full replacement for a mount. For instance, when I click on a document to open it, a temporary file will be downloaded to a temporary folder. So when I save an edited document, it will only change the temporary file, but not change the file on the WebDAV server.

What would be ideal is if the developers of the "webdav://" implementation at KDE turned it into a fuse implementation of a file system! But I have not yet found out who the developers are.

Still an issue with Ubuntu 18.04 and NextCloud 13. Accessing the same server using Konqueror webdavs:// or Windows Explorer (WebDAV mapped as a network drive) is *much* faster.

My experience is the same as @hasi described, but I'm on Ubuntu 18.04. Accessing via Nautilus by typing 'dav://url.com/Folder' is as fast as can be, but mounting it using fstab is extremely slow.

POTENTIAL CLUE: When opening the mounted folder, my download network traffic raises to full speed (10MB/s) for about 2 minutes until folder contents is displayed, then traffic is back to normal.

I'm also affected by this issue in ubuntu 19.10

Also the same case here. Probably we'd like to collect the information to report upstream first to see if the maintainer can gain some insight.

same issue on popos 21.04, I have the same behaviour as Vidvranjek. I believe nautilus does not recognize the folder as a dav mount and just tries to download the entire folder (probably to get file information or similar) instead of doing partial requests (which I don't know if they are implemented yet in davfs2 as far 2016 goes https://savannah.nongnu.org/support/?109044)

Mounting the drive via the "account" feature of popos solves the issue because nautilus sees it as a remote drive and doesn't try to have the same behaviour

It's almost 14 years and I can confirm this unassigned high importance bug is still of relevance.

Still present in Ubuntu 22.04. :-(