WebDav Nexcloud as a sync strategy

Dear DT community,

I am considering setting up WebDAV on locally hosted Nexcloud to replace the existing iCloud CloudKit sync.

I haven’t used Nextcloud, but I have read about its capability to expose a WebDAV URL that could be configured as a sync store in DT. I envisage Tailscale in the middle, providing secure access for devices on the same Tailnet, with TS SSL-enabled. In this scenario, I would consider not protecting the sync store with a password, since it will only be hosted on my system.

Google Gemini suggests that it is possible with the two recommendations:

  1. Disable the Nextcloud desktop client folder used by WebDAV for DEVONthink so that the synced zipped bundles don’t appear in Finder on macOS.
  2. Enable Redis to handle transactional memory caching to avoid possible HTTP errors when DT sends “thousands of rapid HTTP requests” during initial or otherwise large syncs.

Has anyone explored this style of sync, and if so, would it be a recommended, stable and supported option? Any other tips, experiences? Would you agree that encrypting this sync store is unnecessary if the underlying local filesystem is encrypted?

Many thanks,

Alex

Why would it be important in any way if the backup folder is visible in Finder?
Why would you install an in-memory database to avoid which HTTP errors exactly?

If encryption is necessary and possibly where, depends on many factors. One of them being if you expose your server to the internet. You don’t say. And why would Tailscale be needed on top of HTTPS?

Maybe this helps

1 Like

Thank you, Chrillek,

In response to your questions in their respective order:

• Sync store (not backup) folder produces a lot of files (clutter). If accidentally modified in Finder, it will present a problem. It’s best to keep it away from the user’s fat fingers.

• Because my home server may not be able to cope with the rate of HTTP requests DT will hit it with a large sync.

• Tailscale is to prevent exposure to the internet and to avoid following the dated 2020 tip you cited about port forwarding, which is not secure to 2026 standards.

• SSL is provided by Tailscale and is required for mobile apps and, otherwise, for an “insecure site” message from the browser.

Hope this answers your questions.

I also want to add that I have now set up Nextcloud, and it appears to work rather well. I am calling on any other DT experts who may have experience with this setup and can provide feedback.

Regards, Alex

I don’t know how relevant this is but I’m running WebDAV on a Synology server, I have a syncstore set up on one “share” and have that share visible in the Finder on one Mac but not on another. It uses SSL that is configured on my Synology (and yes, I have port forwarding, not because I think that it actually prevents an attack but it at least results in fewer attempts). Has worked fine for … 3-5 years now.

2 Likes

And what would Redis do in this context?
I believe that you are imagining a problem. Or Gemini is. Searching for “WebDAV” and “Redis” on the net didn’t reveal anything useful.

And already in 2020 I wrote

An alternative to port-forwarding, which many consider unsafe as it pokes a hole in your firewall, would be a VPN.

“secure” is not an absolute measure, and port forwarding is but one possibility to make the WebDAV server accessible from the outside. Exposing a WebDAV server via HTTPS and portforwarding poses the same risks as exposing any HTTPS server via portforwarding.

The central question is if you need external access to your WebDAV/NAS? Then Tailscale is one way to go. Another one would be to setup a VPN on your router. If you do not need external access, there’s no need to think about port forwarding, Tailscale or VPN.

You can also setup your NAS to use a Let’s Encrypt certificate and a DynDNS service. Voila, SSL and consequently HTTPS. The main advantage of Tailscale is that it builds a private network between all your devices that isolates them from the internet.

As was to be expected. They use it also for CalDAV and CardDAV. The initial sync might take some time but after that you’ll probably not notice any lags.

1 Like

This has been my exact setup since I started using DT/DTTG back in the 2.x version. I’m running on the default 5006 port with an auto-renewed Let’s Encrypt certificate on my Synology, and I don’t get any login attempts beyond my own connections (*). My Synology is restricted to accept connections only from Spain and the Netherlands, but if you want extra security, you could always change the default port.

(*) Apparently, some people assume there’s nothing worth finding behind a WebDAV server.

1 Like

Same here. Synology WebDAV sync, with Synology’s dynamic DNS and TLS for access via IPv6. No VPN, no port forwarding, no DMZ.

It’s worth noting that if you set up the WebDAV server with a password for access, you only need to enter that password in DEVONthink or DEVONthink To Go once, when you set up the sync store. So I’d say there’s really no gain from having passwordless WebDAV, and potentially a lot of danger.

I also use a dedicated account on the Synology box that’s just for WebDAV, and give it no access outside its home directory.

3 Likes

The DynDNS should resolve to the public IP of your router. Or does your NAS have is own public IP address?
In the former case, port forwarding is a must since the devices in your network do not have public IP addresses.
The Synoloy NAS can open the required ports in the router on their own using UPnP.

I use IPv6. All the devices on the network have globally routable addresses. Outside home I mostly care about DTTG on my phone, and mobile Internet in the US is almost all IPv6 — IPv4 is handled by tunneling it through IPv6.

1 Like

And that exact same reason is why I don’t want IPv6 at home. A couple of months ago, my provider replaced my router, and it only works with IPv6, so I had to fight with them to get IPv4 back via tunneling. In the end, I managed it by placing my FritzBox behind the ISP’s router and globally disabling IPv6 on it, because my ISP router stops working if I disable IPv6 in it.

Besides, with IPv6, DT and DTTG wouldn’t connect to my Synology. And I also don’t like the fact that all my devices are visible from outside my router, even if it’s an IP so long that it’s virtually unfindable

So, do you use port forwarding to your Synology or a VPN or … ?

How is that an issue if you do not run any services on them? In some routers (notably a Fritz) you can turn on “stealth” mode which blocks ICMP requests.

I tried with Fritz and Synology VPN but had issues because sometimes it went randomly down. Tried with Tailscale and it was even worse: internet speed at home went to 1 byte/hour.

Currently I have port forwarding, and not any foreign intruder try.

Yes, but they can try using random IP once they know the “fixed” part (that yes, it is not the most probable thing).

Anyway, what it made me not use IPv6 was the problem when my provider changed the “fixed” IP part. Then I will need to use a IPv6 compatible DDNS (and I think the Synology one does not have that option) and start messing with the configuration of all. Or solve via any other way… as my employer says in Spanish (he is Dutch): “muy complicado”. It works, if it works, don’t touch. I only had to connect my Fritz in one of the network sockets of the company router and let it be the DHCP server.

It does. But the Fritz must be told to disable DNS rebind for your Synology domain (if you’re using that).

Yeah, that’s a PITA.

1 Like

Besides, with IPv6, DT and DTTG wouldn’t connect to my Synology.

That’s definitely a bug somewhere. My home network is IPv6-first and everything works. Perhaps the Fritz box is on the fritz? :grin: