Bug 147716 - Error dialog instead of WebDAV authentication - WebDAV completely broken
Summary: Error dialog instead of WebDAV authentication - WebDAV completely broken
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: WebDAV
  Show dependency treegraph
Reported: 2022-03-01 19:16 UTC by Joe Breuer
Modified: 2022-09-06 23:00 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

This ebuild works with webdav on my system (19.17 KB, text/plain)
2022-04-11 10:32 UTC, J. Roeleveld

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Breuer 2022-03-01 19:16:46 UTC
I'm using app-office/libreoffice to edit documents residing on an Alfresco server, accessing those via WebDAV (WebDAVs / https / SSL).

After upgrading from to, WebDAV access no longer works - choosing the remote service (or trying to add a new one) in LibreOffice's "Open Remote File..." dialog will give an "Nonexistent file." error. It is not possible to open any WebDAV resources either from the "Open Remote" menu item, nor from the recent documents items.

This happens with all WebDAV Services / URLs I have configured / access to; KDE's Dolphin accesses those WebDAV locations without any issues.

I've installed a build with debug enabled and turned on "most" logging with SAL_LOG="+INFO+WARN-INFO.vcl.schedule-INFO.i18nlangtag-INFO.sal.osl.condition-INFO.vcl-INFO.drawinglayer"

This shows the error dialog happening immediately on the first WebDAV reply of 401 Unauthorized, which should rather trigger a query for credentials:

info:ucb.ucp.gio:131336:131336:ucb/source/ucp/gio/gio_provider.cxx:36: QueryContent: https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/
info:ucb.ucp.gio:131336:131336:ucb/source/ucp/gio/gio_content.cxx:81: New Content ('https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/')
info:ucb.ucp.gio:131336:131336:ucb/source/ucp/gio/gio_content.cxx:939: Content::execute open
warn:ucb.ucp.gio:131336:131336:ucb/source/ucp/gio/gio_content.cxx:399: ignoring GError "HTTP Client Error: Unauthorized" for <https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/>
warn:uui:131336:131336:uui/source/iahndl.cxx:237: replaceMessageWithArguments: No arguments passed!
info:toolkit:131336:131336:toolkit/source/awt/vclxwindows.cxx:2279: XDialog created
( ^ Some private information hidden ^ ) 

The XDialog mentioned corresponds to the "Nonexistent file." error dialog showing on screen.

Steps to Reproduce:
1. Start LibreOffice
2. Use "Open Remote...
3. Choose an existing WebDAV service, or create a new one

Actual Results:
A nondescript error dialog "Nonexistent file." is shown. It is not ever possible to browse or open WebDAV resources, not even from the Recent Documents either.

Expected Results:
Browsing and accessing directories and documents at a WebDAV location should be possible, just like in LibreOffice up to at least

Reproducible: Always

User Profile Reset: Yes

OpenGL enabled: Yes

Additional Info:
I've found a possibly related issue where credentials are not correctly queried/used for ssh remote resources:


Since I'm using gentoo, there's a corresponding platform bug report:

Comment 1 Julien Nabet 2022-03-01 21:01:51 UTC
Just for your information, from LO 7.3 LO uses Curl for WebDav instead of Neon or Serf lib. (see https://blog.allotropia.de/2022/02/07/improving-libreoffices-network-file-access/).

So even if there's indeed some bugs in 7.2.5, I'd be astonished it could be fixed in 7.2.6 or even 7.2.7 (see https://wiki.documentfoundation.org/ReleasePlan/7.2) but I may be wrong.

Would it be possible you give a try with LO 7.3.0 ?
Comment 2 J. Roeleveld 2022-03-02 09:30:33 UTC
I just tested this issue with 7.3.1 and am sorry to report that the issue also exists in that version.
Comment 3 Joe Breuer 2022-03-02 11:53:17 UTC
(In reply to Julien Nabet from comment #1)
> Would it be possible you give a try with LO 7.3.0 ?

For me it's also confirmed broken in exactly the same way in
Comment 4 Joe Breuer 2022-03-02 12:42:21 UTC
I've dug a little bit deeper - with SAL_LOG="+INFO.ucb", LO 7.1 logs a ton of information pertaining to the HTTP requests underlying WebDAV, ie things like:

info:ucb.ucp.webdav:515394:515394:ucb/source/ucp/webdav-neon/webdavcontent.cxx:449: Content::execute: start: command: open, env: present
info:ucb.ucp.webdav:515394:515394:ucb/source/ucp/webdav-neon/NeonSession.cxx:651: NeonSession ctor - URL <https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/>
HTTP session to https://hidden.host.name:443 begins.
ssl: SNI enabled by default.
info:ucb.ucp.webdav:515394:515394:ucb/source/ucp/webdav-neon/NeonSession.cxx:868: OPTIONS - relative URL </alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/>
Running pre_send hooks
Sending request headers:
OPTIONS /alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/ HTTP/1.1
Connection: TE, Keep-Alive
TE: trailers
Host: hidden.host.name
Pragma: no-cache
User-Agent: LibreOffice

Sending request-line and headers:
Doing DNS lookup on hidden.host.name...
req: Connecting to
Doing SSL negotiation.

With LO 7.2, NONE of this is logged - the only things logged at all within ucb are within/below ucb.ucp.gio:

info:ucb.ucp.gio:516758:516758:ucb/source/ucp/gio/gio_provider.cxx:36: QueryContent: https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/
info:ucb.ucp.gio:516758:516758:ucb/source/ucp/gio/gio_content.cxx:81: New Content ('https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/')
info:ucb.ucp.gio:516758:516758:ucb/source/ucp/gio/gio_content.cxx:939: Content::execute open
warn:ucb.ucp.gio:516758:516758:ucb/source/ucp/gio/gio_content.cxx:399: ignoring GError "HTTP Client Error: Unauthorized" for <https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/>

Digging around the ucb providers in OpenGrok, it seems to me that the gio provider is erroneously chosen instead of the WebDAV one.

My source-reading fu is currently not strong enough to find the place where the decision for a particular ucb provider is actually made, and what that decision is based on.
Comment 5 Julien Nabet 2022-03-02 17:36:56 UTC
Thank you Joe for your detailed feedback.

Michael: thought you might be interested in this one since it concerns WebDav.
Comment 6 Michael Stahl (allotropia) 2022-03-03 19:11:29 UTC
so the problem is apparently that in 7.2 an URL with https:// is handled not by webdav UCP but by gio UCP - that is indeed quite surprising.

if you have basic git skills and can download a ~10gb repo, possibly this potential regression could be tracked down via bibisect, in the linux 7.2 repo:


Comment 7 Joe Breuer 2022-03-31 17:01:10 UTC
At my current everyday location, I don't have the bandwidth, and also am space-constrained to do a bisection on a 10GB repo.

I'll try to remember when I'm at a place with better connectivity/infrastructure next.

If anyone else is in a better position to do this, your help would be greatly appreciated.
Comment 8 Joe Breuer 2022-04-07 08:35:15 UTC
A small bit of additional information: (Today,) I have remote access to a Windows system that would be suitable for the bisection.

Alas, this problem seems Linux-specific - installing or on Windows, they both work fine with the same WebDAV share.

I'll see about figuring out a system/VM I can test this on under Linux.
Comment 9 Joe Breuer 2022-04-07 19:49:21 UTC
@J. Roeleveld: What distribution could you reproduce the problem in?

The plot thickens. Using the libreoffice-still 7.2.6-1 package in Arch Linux, WebDAV works as expected (same as under Windows).

So I tried with the 7.2.5 "Basic" AppImage that I could find on my gentoo system, where I first experienced the issue. Again, WebDAV works correctly in that version.

Next, I moved the libreoffice configuration directory (in ~/.config/libreoffice) out of the way and tested again with the gentoo native package/build - and I still get the "Nonexistent file." error.

At this point, it looks like there's something up with the gentoo build/package, rather than LO itself.

I'd be super interested to hear back from J. Roeleveld, if he's also using gentoo, or, if another distribution, what's similar between the ones where the bug occurs.
Comment 10 J. Roeleveld 2022-04-08 07:01:59 UTC
As also mentioned in the bug-tracker for Gentoo, I am using Gentoo and do my best to keep my systems fully updated.

To also answer here (for completeness), I have not changed the USE-flags for libreoffice.
Comment 11 Joe Breuer 2022-04-11 08:34:42 UTC
I got a testing environment put together, a stripped-down and minimal version of gentoo as I use it / as it comes out of the box, as it were. The there-current app-office/libreoffice- package exhibits the bug, ie "Nonexistent file." instead of WebDAV browsing / file access.

I then had a look at the bibisection.

Similar to what I found in comment 8 and comment 9, the bug does not occur with either the newest 7.2 bisection build:

commit 1b8c93949b24204fe8a7b7105215c712aa132547
Date:   Tue Mar 15 11:48:19 2022 +0100
    source 6fb5a87e31b7df01f4b212ab979ae57e8d4ab4fb

nor with the oldest:

commit 1810f056660f59f79e76b8bdd6f5b902c27ce14f (HEAD, tag: oldest)
Date:   Thu Nov 26 15:52:40 2020 +0100
    source 738bcf5e9a8c443d60c29c3a8068e8c16c72638a

Which means there's something (significant in this respect) different about the gentoo builds of LibreOffice from the ones in the bibisection repository.

I've since also tested the binary build that's available for/on gentoo (as app-office/libreoffice-bin- WebDAV also does not work, but it is subtly different: the "Open Remote..." file dialog stays empty after configuring a WebDAV service, there is no error dialog.

As J. Roeleveld also suggested - great idea! - I'll start having a look what those differences might be; using the documented release build options & environment as a starting point:


For reference/contrast, here's the configuration that the source build in gentoo uses:

./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --docdir=/usr/share/doc/libreoffice- --htmldir=/usr/share/doc/libreoffice- --libdir=/usr/lib64 --with-system-dicts --with-system-epoxy --with-system-headers --with-system-jars --with-system-libs --enable-build-opensymbol --enable-cairo-canvas --enable-largefile --enable-mergelibs --enable-python=system --enable-randr --enable-release-build --disable-breakpad --disable-bundle-mariadb --disable-ccache --disable-epm --disable-fetch-external --disable-gtk3-kde5 --disable-online-update --disable-openssl --disable-pdfium --with-extra-buildid=Gentoo official package --enable-extension-integration --with-external-dict-dir=/usr/share/myspell --with-external-hyph-dir=/usr/share/myspell --with-external-thes-dir=/usr/share/myspell --with-external-tar=/var/tmp/portage/app-office/libreoffice- --with-lang= --with-parallelism=6 --with-system-ucpp --with-tls=nss --with-vendor=Gentoo Foundation --with-webdav --with-x --without-fonts --without-myspell-dicts --with-help=html --without-helppack-integration --with-system-gpgmepp --without-system-jfreereport --without-system-libcmis --without-system-sane --disable-report-builder --enable-sdremote-bluetooth --disable-coinmp --enable-cups --enable-dbus --disable-debug --disable-evolution2 --disable-firebird-sdbc --disable-gstreamer-1-0 --enable-gtk3 --enable-kf5 --enable-qt5 --disable-ldap --disable-odk --disable-pdfimport --disable-postgresql-sdbc --disable-skia --without-lxml --without-system-coinmp --without-gdrive-client-id --without-gdrive-client-secret --without-java --without-doxygen --enable-dconf --enable-gio --disable-ext-nlpsolver --disable-scripting-beanshell --disable-scripting-javascript --disable-ext-wiki-publisher

The --disable-openssl does stick out a bit, although --with-tls=nss is selected explicitly. I've just checked, the working build does the same. Hmm, and what does --enable-gio do, exactly.

Ooh, and here is a strong hint in the ./configure output:

checking for webdav library... none, disabled

... although net-libs/neon-0.32.2 is available on the system, but the gentoo build process typically takes care to isolate packages (that are not explicitly used as dependencies), and it isn't listed there.

I have an idea how to set that right in the gentoo build:
  webdav? ( net-libs/neon )
  $(use_with webdav neon)
and I will be trying this out next.
Comment 12 J. Roeleveld 2022-04-11 09:16:08 UTC
I'm guessing the "neon" bit is likely:

# grep "checking for webdav library" /var/log/portage/app-office\:libreoffice-*
/var/log/portage/app-office:libreoffice- for webdav library... neon
/var/log/portage/app-office:libreoffice- for webdav library... neon
/var/log/portage/app-office:libreoffice- for webdav library... neon
/var/log/portage/app-office:libreoffice- for webdav library... none, disabled
/var/log/portage/app-office:libreoffice- for webdav library... none, disabled
/var/log/portage/app-office:libreoffice- for webdav library... none, disabled

As you can see, 7.1.x all found "neon", 7.2.x and 7.3.x did not on my system.
Comment 13 J. Roeleveld 2022-04-11 09:19:01 UTC

# grep neon *
grep: files: Is a directory
libreoffice-     >=net-libs/neon-0.31.1:=
libreoffice-             --enable-neon

# grep neon *
grep: files: Is a directory
libreoffice-  >=net-libs/neon-0.31.1:=
libreoffice-     >=net-libs/neon-0.31.1:=
libreoffice-  >=net-libs/neon-0.31.1:=
libreoffice-     >=net-libs/neon-0.31.1:=
libreoffice-7.3.9999.ebuild:    >=net-libs/neon-0.31.1:=
libreoffice-9999.ebuild:        >=net-libs/neon-0.31.1:=

Are we missing " --enable-neon " from the " myeconfargs= " list in the ebuild?
Comment 14 J. Roeleveld 2022-04-11 09:22:08 UTC
(Not sure how to edit comments here)

"--enable-neon" was removed in the same commit as where "--with-webdav" was added. (checking the git-commits for libreoffice-9999)

This commit was done on 2022-10-31
Comment 15 J. Roeleveld 2022-04-11 09:47:28 UTC
Compile is still running, but the configure output is now showing:

checking for webdav library... neon

I added the following configure-flag to the ebuild:


It is necessary to actually list the library like this.
Comment 16 J. Roeleveld 2022-04-11 10:32:21 UTC
Created attachment 179448 [details]
This ebuild works with webdav on my system

I added  " +webdav " to IUSE

I added "webdav? ( net-libs/neon )" to COMMON_DEPEND

I added " --with-webdav="neon" " to myeconfargs

The last one should still be linked to a USE-flag.

But this is a step in the right direction.
Comment 17 Joe Breuer 2022-04-11 13:51:56 UTC
I can also confirm that configuring with:


instead of


yields a WebDAV-enabled and -working LO (under gentoo).

I'll submit a suitable build patch over there.
Comment 18 Dylan 2022-09-06 23:00:46 UTC
I'm also experiencing this same issue on the debian buster libreoffice package. I've tried the debian buster-backports build. Both experience this problem.