Flint2 WebDAV Share Automounting

Hi all, I am trying to mount a USB drive on my new Flint2 using WebDAV from several linux client machines and currently have two problems:

  1. When mounted via fstab, the mount behaves awkwardly. Browsing becomes very slow when a large file is present in the browsed folder. It seems like the complete folder is downloaded on browsing, logs support this. Also file copying seems to be awkwardly delayed and transfer speeds seem wrong.
  2. Automounting via fstab doesn't work, because of the gl.inet self-signed certificate. I had this working, but after enabling guest network with a dedicated IP range, the certificate carries the guest network IP as target and therefore creates a host mismatch.

Would be awesome if you guys could help me sorting out either of these issues.

Details:

  • Flint2 Firmware: 4.8.0-op24 (beta2)

  • Connected Drive: External NVMe SSD via USB3.0, ext4-formatted.

  • I used the Gl.Inet UI to create a https-based WebDAV-Share with a username/password combination for r/w access.

  • Client OS: Linux Mint 21.3, connected via WiFi

  • Note: When I mount the WebDav-Share via Nemo, problem 1 does NOT occur. The share behaves exactly as I would expect, reaching up/download speeds > 100MB/s. However, this way I cannot automount during boot, have to actually manually create the mount every time via nemo and cannot create a mount point in the shared drive directly, but rather get something like "drivename/mount_folder/actual_mount" instead of "actual_mount/" directly.

Details Problem 1:

  • My fstab entry is the following:
  • https://[flint2.ip]:[WebDavPort]/[drivename]/[mount_foulder]/ /mnt/net_drive davfs user,noauto,rw,_netdev 0 0
  • Obviously noauto is currently set since things are not finalized.
  • In /etc/davfs2/davfs2.conf I had to set "use_locks 0", otherwise I was not able to create files on the mount. This again was only necessary for the fstab-based mount, the nemo-mount doesn't have that problem.
  • When adding "debug most" to davfs2.conf, I get the log hint from journalctl -f, that when browsing the share cache size is significantly too small, clearly suggesting the folder is indeed downloaded on browsing already. This does NOT happen for the nemo-created share.

Details Problem 2:

  • Before adding the guest network, I was able to add the glinet certificate to my local certificate store, and the connection worked without asking for the untrusted certificate. But after activating the guest network with dedicated IP range (which I want to use), the certificate after Flint2-reboot always changes to this IP. Since obviously I'm on the main network, there is a host conflict and the added certificate doesn't help anymore. ChatGPT suggested to recreate the certificate manually, then writeprotect it, so it doesn't get overwritten on reboot. Is there a better solution?

ChatGippity is full of shtye but what else is new? Yeah, there is: your own wildcard certificate issued by your own private cert authority.

Uhhhh... my scratch notes are messier than I would like but I've got something I can probably reproduce in a three or four days & turn into a proper HOW-TO. Are you okay with re-issuing your certs every 27 months? That's a current limitation that I have other notes on resolving but haven't done yet:

I would be totally ok with re-issueing it every 27 months :wink: The mkcert tool sounds like a quite deep operation on several devices, which I would prefer avoiding, I think.

It's not too bad at all; about a dozen lines to get it installed on a OWRT device after copying over the root CA cert & the wildcard cert. I'm probably going to script the process to make it even quicker, easier as I have OWRT VMs & a handful of GL.iNet, other OWRT devices to deploy them on. Then it's just a matter of updating the confs for the individual daemons that need to use it (eg: WebDAV, FTP/S, nginx, uhttpd, etc.).

The 'trick' is the root CA cert must be installed on every device you're going to use to connect to the OWRT device or it won't establish the TLS connection, of course. On your computer you use to create the CA that is suppose to be done automatically. I can confirm that is the case using Linux.

Hi

We have reproduced Problem 2 and will forward it to our R&D team for further investigation and a fix.

Currently, please try changing the LAN IP address once (for example, to a different address) and then switch it back. This should temporarily resolve the issue.