Nextcloud was probably my first foray into proper self-hosting. I ran it on Linode for a few years before moving it to run at home over Tailscale.
It was my self-hosting gateway to all there was to come – from RSS aggregation through to HomeAssistant, recipe management, and business and accounting services (and everything in between). As such, it was a sad day last week when I docker compose down’d my Nextcloud deployment for the final time.
I originally started using Nextcloud as a replacement for Google Drive after reading stories about the risks of centralising one’s digital life on a single service and account (though, later, my motivations moved more towards data sovereignty and control) and thus my primary goal with Nextcloud was to use it purely as a Drive replacement – a place to store, sync, and backup my files.
A key factor in my choice to use Nextcloud was its cross-platform compatibility; it offers native apps for servers, desktops, and my phone, with great integration into the OS (such as Finder on macOS and the Files app on iOS). This would allow Nextcloud to fit nicely into my workflows both at home and when out and about.
File-storage and sync is only a small part of what Nextcloud offers. In reality, it’s a full office suite, providing calendars, contacts, photo management, collaboration tools, email, and much more – both natively and via its apps ecosystem. Over the years I’ve dabbled in the various other offerings: at one time I used it as my photo backup (before moving this over to Photoprism), I’ve used it as a source of truth for my calendars and contacts, I’ve spent months using it as my go-to email client, and I’ve used its WebDAV capability as a back-end for when I used to use Joplin for notes.
In recent years it’s reverted back to only being a file-sync system for me, and since I only run it for myself, it is a little overkill for my basic needs. Its usefulness and my reliance on it for file-sync always kept it relevant, however.
Self-hosting anything can have substantial overheads – both computationally and in terms of time commitment. Like many people, I consider this investment part of the price for getting true data sovereignty. Though, more recently, the Nextcloud overheads have begun to make me question its value to me. Nextcloud is one of those apps that does need fairly regular maintenance: ensuring indexes and migrations are correctly applied, conducting upgrades, and keeping the in-system apps up-to-date are all part of the job in administering an instance. Inevitably things sometimes go wrong, which results in additional hours of time in rolling-back versions, restoring backups, and trying to understand how to manually apply failing automatic updates and migrations. This level of “investment” didn’t seem worth it to me anymore.
I appreciate that Nextcloud’s goals are not really to support individual user instances that only require the minimal feature set, and thus this is not a criticism of Nextcloud itself in any way – large, complex systems always have operational overheads and usually have dedicated staff to administer them.
All I actually really need, I came to realise, is a simple filesystem. I don’t need a database, fancy web UIs, and all the work that goes into running and maintaining these. As such, last week I took the dive and made the decision to switch away from Nextcloud.
I already run Syncthing to sync other sets of files and content between computers and servers, and was able to easily move the Nextcloud-managed files into Syncthing directly from Nextcloud’s filesystem-backed storage.
The issue, then, was restoring my usual remote file workflows from my phone. iOS’s restrictions mean that Syncthing can’t really function correctly on iPhones, and even workarounds for these often seemed flakey. I was keen to find a solution that would provide good and robust integration with the iOS Files app to truly cater to the needs of my day-to-day tasks.
My first thought was around setting-up an NFS (Network File System) share. However, iOS is not able to mount NFS shares. After some research, I discovered that SMB (Server Message Block) is natively compatible. I’m not familiar with SMB myself, but it turned out to be fairly simple to setup Samba to expose the Syncthing directory and make it mountable by my phone over SMB. When combined with Tailscale, this then let me connect and access my files even when physically away from my usual network.
Once Samba was installed, I needed to make a couple of changes to the configuration file (/etc/samba/smb.conf), before restarting the service again, in order to get things working.
First, I added the following line to the top of the [global] section of the config in order to allow read/write access from iOS:
vfs objects = streams_xattr
Secondly, to expose the actual directory, I added the following block to the share definitions area:
[files]
comment = My useful files
read only = no
path = /path/to/syncthing/directory
guest ok = no
For authentication, I added a new Samba user by running smbpasswd -a will.
Whilst SMB on iOS is pretty basic, it gives me what I need for my relatively simple workflows, and the overall result is now a robust file-“sync” system across all my machines. I also find Syncthing to be more performant and reliable than Nextcloud (and without all the additional overheads) when it comes to its sync capability, and offers better visibility over what’s going on behind the scenes.
Nextcloud may feature again in my personal life some time in the future, but for now I am happy to have moved on. I certainly still advocate for it for larger team collaboration tools in place of more commercial services.