Nextcloud Nautilus integration

I just cannot figure out the proper syntax for the Nextcloud server address to input into Nautilus. (The instructions here are not helpful I’m afraid.) Can anyone post the proper syntax please? I also tried via Gnome Control Center, to no avail:

blendOS (rolling), Nextcloud server on TrueNAS:

hey @Aqua1ung welcome back :ok_hand:

can you please describe your setup? Support template. Please use this when you request support

from your screenshot it looks like you’re trying to mount webdav in Nautilus via dav2fs without a valid certificate? using davs:// is implying “s=secure” as in SSL, by the looks of that unmountable location you’re trying to mount a local not HTTPS-secured network device. make sure you have a valid certificate for your instance and use FQDN.

your target should look something like this;
davs://dad@cloud.yourdomain.tld/remote.php/dav/files/dad

If your server connection is not HTTPS-secured, use dav://
dav://dad@your.cloud.server.ip/remote.php/dav/files/dad

same issue here, GCC is expecting a valid certificate, that’s how dav2fs works i.e.:
https://example.com/nextcloud/remote.php/dav/files/USERNAME/

1 Like

Yep, this is precisely the syntax that I have been using. My Nextcloud server is not secure (my LAN is behind a WireGuard server). Everything is … insecure :blush:

And here below is a screenshot, where you can see that Nautilus just does not like this syntax (red text, with the “Connect” button grayed out)!

no its not the syntax that dav2fs and Nautilus dislike… its your air gapped uncertified Nextcloud instance that’s the issue :flushed_face:

To be honest, I’m not so sure about that. I’d say that WebDAV access should generally work, even if Nextcloud is only served via plain HTTP.

Unfortunately, I cannot test this since I don’t run any instances without HTTPS. However, I can confirm that the syntax is definitely correct.

A few other things that could potentially be causing the issue:

On the Nextcloud side:

  • Web server and/or reverse proxy configuration.

On the client side:

  • Missing dependencies. For example, on Arch Linux, the gvfs-dnssd package must be installed for it to work.

… neither do I

… probably, but without dav2fs installed and using default dav or mounting the device in fstab as root with user r/w permissions.

no one is saying your setup is insecure… the webservice simply does not have a valid signed certificate! you could try a self-signed certificate, but there are caveats!

Self-signed certificate is easier to setup than Let’s Encrypt certificates, but will cause warnings in browsers and due to being very basic won’t work with some applications.

I don’t think self-signed certificates would help in this case. Usually, they cause more issues than plain HTTP. Except, of course, for things that simply don’t work without HTTPS. However, I’m pretty sure that’s not the case for gvfs.

I still believe the problem lies elsewhere, most likely on the client side.

@Aqua1ung
Which distro are you using, and what version of it?