WebDAV extremely slow

Bug #185986 reported by glaroc
276
This bug affects 53 people
Affects Status Importance Assigned to Milestone
davfs2 (Ubuntu)
Confirmed
High
Unassigned

Bug Description

Binary package hint: davfs2

I successfully configured and mounted a WebDAV server in Ubuntu 7.10 (x86_64) using davfs2 (1.2.1-3), but the navigation is extremely slow. It takes almost 1 minute for a given folder to show up, and it crashes Nautilus or even Firefox. Navigating to the same folders in Windows is a lot smoother and faster. I had the same issues with 7.04.

This problem seems to be experienced by other users as well:
http://ubuntuforums.org/showthread.php?p=4204410&posted=1#post4204410

Revision history for this message
Nuno Santos (zoryn1) wrote :

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

Revision history for this message
Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 8.10 or 9.04?

Changed in davfs2:
status: New → Incomplete
Revision history for this message
lewvip (lewvip-163) wrote :

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

Revision history for this message
lewvip (lewvip-163) wrote :

And also reproduced on 8.10

Revision history for this message
Mark (mlvarnell) wrote :

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.

Revision history for this message
William Siddall (williamsiddall) wrote :

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.

Revision history for this message
Stefan Seidel (seidler2547) wrote :

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

Changed in davfs2 (Ubuntu):
status: Incomplete → New
Revision history for this message
SMut (steffen-webanimations) wrote :

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?

Revision history for this message
SMut (steffen-webanimations) wrote :

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.

Revision history for this message
p3tris (p3tris) wrote :

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..

Revision history for this message
Marc G. (marc-gu) wrote :

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

Revision history for this message
BenoitLBerube (benoit-louis-berube) wrote :

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.

Simon Déziel (sdeziel)
Changed in davfs2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Wolfgang_Pfalzgraf (wolfgang-pfalzgraf) wrote :

same Problem with ubuntu 9.10 and Konquerror or Dolphin

Revision history for this message
SMut (steffen-webanimations) wrote : Re: [Bug 185986] Re: WebDAV extremely slow

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

Changed in davfs2 (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Vangelis Tasoulas (cyberang3l) wrote :

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

Revision history for this message
jkruse (online-jannkruse) wrote :

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.

Revision history for this message
indium (indium) wrote :
Download full text (4.1 KiB)

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...

Read more...

Revision history for this message
indium (indium) wrote :
Download full text (4.5 KiB)

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...

Read more...

Revision history for this message
Craig Harding (craigwharding) wrote :

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.

Revision history for this message
Mr.Gosh (mr-gosh) wrote :

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

Revision history for this message
Michael Luthardt (michalu) wrote :

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

Revision history for this message
Paul Tux (pdhtux) wrote :

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.

Revision history for this message
Why Fullname (6-launchpad-frundle-com) wrote :

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

Revision history for this message
oliver nybroe (olivernybroe) wrote :

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

Revision history for this message
Alexander Sell (ubuntu.alex) wrote :

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.

Revision history for this message
Michael (miwait00) wrote :

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?

Revision history for this message
Janus (reslayer-mail) wrote :

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?

Rolf Leggewie (r0lf)
Changed in davfs2 (Ubuntu):
importance: Medium → High
Revision history for this message
Minosone (menno-pleijster) wrote :

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

Revision history for this message
Frank Poetzsch-Heffter (f-p-h) wrote :

Same in Ubuntu 16.04.

Revision history for this message
hasi (whynot-nurfuerspam) wrote :

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

Revision history for this message
hasi (whynot-nurfuerspam) wrote :

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.

Revision history for this message
Gunter Ohrner (gohrner) wrote :

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.

Revision history for this message
Vidvranjek (vidvranjek) wrote :

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.

Revision history for this message
flip101 (flip101) wrote :

I'm also affected by this issue in ubuntu 19.10

Revision history for this message
Woodrow Shen (woodrow-shen) wrote :

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.

Revision history for this message
fuomag (fuomag) wrote (last edit ):

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

Revision history for this message
René Schäfer (resch78) wrote :

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

Revision history for this message
No Spam (spam-receiver) wrote :

Still present in Ubuntu 22.04. :-(

Revision history for this message
Xavier (moxyp) wrote :

Still present on Ubuntu 23.10. I've tried on a webdav drive on Nextcloud 27.1.5. I've installed davfs2 version 1.6.1-1.

The davfs2 french documentation on Ubuntu-fr says that 'rclone' is a much better and faster replacement for davfs2 : https://doc.ubuntu-fr.org/davfs2

So I've installed 'rclone' and it works like a charm ! Go to : https://rclone.org/webdav/ for instructions.

sudo apt install rclone
rclone config
<< answer the questions as suggested on https://rclone.org/webdav/ >>

Test if it works :
rclone lsd my_rclone_name:

To mount it permanently on a specific empty folder : https://rclone.org/commands/rclone_mount/

On Linux :
rclone mount my_rclone_name: /home/$USER/my_dir &

Super simple !

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.