Help me figure it out. I’m trying to connect to the cloud in GNOME, Fedora 42. According to the instructions, you need to specify the server in the file manager in the NETWORK section and specify the password. Server: davs://here_my_login@webdav.cloud.mail.ru:443`
This method works.
Website with instructions for Linux: https://help.mail.ru/cloud_web/app/webdav/
But if I connect through the settings, the connection does not occur.
Settings → Network accounts ->Calendar, contacts, files (WebDAV)
Server: davs://webdav.cloud.mail.ru
and I indicate the login + password.
The account is accepted but the connection produces an error.
"Unable to access location " HTTP error: Not Found
When entering the address in Settings → Online Accounts → Calendar, Contacts and Files (Webdav), try leaving the protocol out from the URL, which in your example would become: webdav.cloud.mail.ru.
What I can think of is that given you have to use the 443 port for direct access, you could append it when setting up the connection in GNOME Online Accounts as well.
As far as I know, GNOME Online Accounts does not support generic WebDAV connections (only for nextcloud when setting up a nextcloud account). Nautilus on the other hand speaks WebDAV.
I’ve seen issue reports and requests for enhancements but as far as I know, nothing has been implemented.
Maybe in the past it didn’t support generic WebDAV, but currently it does, I am using one such service (i.e. standard WebDAV, not a Nextcloud instance) w/o issues. GOA even has separate entries for Nextcloud and for standard WebDAV.
For what it matters, I have a webdav server (powered by Apache) and if I configure it in GNOME Online Accounts (I specify the server address without https or the port number, the username and the password) the mount point appears in Nautilus (Files), but it doesn’t work.
Like you. But with a different error.
So, my conclusion is that probably the webdav server is supposed to host some page (like the .wellknown ones) describing where the webdav paths are located or the like.
@alciregi , for reference, I am using the same provider as described in the GOA issue tracker linked above (mailbox.org), and I have no issues accessing the files via Nautilus whatsoever. It might be though that I started using this service sometime last year, after the issue having been fixed.
Looking at the fix, it appears that GOA needs to handle these particular cases individually, probably as a result of the “looseness” of the WebDAV standard.
That’s correct, I believe I have an issue open for this. The short story is that hostname:443 is technically a valid URI, but depending on parsing hostname could be the URI scheme and 443 could be the hostname.
Since we can expect the only URI schemes used are http(s) and dav(s), we should be able to guess, if it is not one of those.
I have landed a few fixes for this in recent months and here’s the short answer again. All WebDAV services are technically file based, and unlike CalDAV/CardDAV there really isn’t a .well-known or DAV header field to make a good guess.
Because Nextcloud/ownCloud are so popular, we treat the /remote.php/webdav path as a “well-known”, but for some reason a few implementations or server configurations will still respond as though it’s a valid endpoint, even if the path doesn’t exist at all.
If there are some configurations this broken for, especially popular ones like Fastmail or mailbox.org, please open an issue and I can try to backport a fix. Otherwise, you may have to adjust your server configuration or use the Files entry, which will override/skip auto-discovery.
Thanks for the link here. I’m guessing mail.ru is pretty popular, so I think the best bet is to hardcode an override, like we do for Fastmail/mailbox.org. I’ll have a look at that tomorrow and follow-up on the issue you opened.
I’m wondering if users overriding the server address in Settings → Online Accounts → WebDAV → Server address (top)* with a server address+path (or just relative path) below in Server addresses (Optional) → Files field could save the trouble of hardcoding the paths of specific services. Taking mailbox.org as an example[1], one would be using dav.mailbox.org as general server address, and dav.mailbox.org/servlet/webdav.infostore/ as file-specific address.
I imagine there will always be WebDAV servers/services with magic detection not working properly.
Not necessary anymore, I know, just for the sake of an example. ↩︎
Do you mean it’s working as override from the beginning, i.e. WebDAV for mailbox.org would have worked even before, without the hardcoded fix, if one would have entered the whole path (dav.mailbox.org/servlet/webdav.infostore/) in the Server Addresses (optional) field?
I never thought about that section in detail, but somehow considered that the optional Files address would only be needed if someone would want to have the mounted DAV FS start not at the root, but rather lower in the file system hierarchy.
Yes, that’s correct. It hadn’t occurred to me it might look like it’s for modifying a URL. I suppose it’s possible we could use auto-discovered data to fill in those entries, that might make it clearer what’s happening
Sorry, I’ve just remembered I didn’t reply to this. Yes, that would probably be helpful. However, the user experiences the issue at a later stage, and if they then go back to check the settings, and click on the Online Account setup, they will not see the path anymore, given that only the Account Name and the 3 checkboxes are presented.
I wonder if an additional verification could be performed when setting up the WebDAV account. If the user would receive the “HTTP: Not Found” (as described by the OP, or a more human-readable) error at that stage, with the auto-discovered data filled in, as suggested, that might pinpoint the issue to the user.
