Moving from Seafile to Nextcloud?

Like you (probably) I have need of something like Dropbox - a bunch of files that I need access to from various places and that I want to work with as though they were just there, on my computer like any other files.

However I just don't trust Dropbox. Icky, US corporate giant that could access all my data? With Trump pressing US companies to reveal more and more data, even if it's held in a different country? No ta. Not that I have any big secrets - it's just that information is power, and there's just too much of that in the hands of a very small set of tech giants; you know, the ones that control what news we see, which friends we can communicate with, which basic services we can access...

So for years I've been using Seafile, a self-hosted Dropbox-like thing. It's been really good. I can access files on my laptop, my phone and basically anything with a web browser. Sync works pretty reliably and it's fast. Originally I tried OwnCloud but on trying to upload several thousand small files and seeing "6 hours remaining..." and seeing an enormous load on my server, just for <100MB files, I had given up on it. That was a few years back.

The next shiny thing? Nextcloud

I recently came across Nextcoud because of an article about its audio and video messaging capabilities. It looked like the project had come on leaps and bounds, going beyond the basic file sync operations and I thought I'd give it a whirl. I read lots good about it, in fact the only thing that put me off it was a post on a nextcloud forum by someone rather arrogantly refusing to add Seafile to its comparison page. Seafile is great technology, but owncloud/nextcloud have ensured that people know about them at every turn, and that's attracted users and developers alike.

Installing Nextcloud on my Debian 9 / MariaDB / PHP 7.0 VM was fairly straight forward but could have been easier. I did not want to use the snap package because I've never actually used one that's worked(!) so I used the zip download. The instructions assume that you will make the entire codebase writable by the user (e.g.www-data) which I dislike. Having once experienced a hack where someone was able to use a vulnerability in a 3rd party library to rewrite and create php files in my webroot I like to keep them locked them down. The files will only need changing when I install an update. There was nothing to tell me which dirs actually needed write access (turns out it's "config"(!), "apps" and "data") so it was trial and error to discover this.

After completing the installation with the web based wizard it was all up and running. Much simpler to install than Seafile which involved opening ports and using reverseproxy etc.

The sync clients

I installed the AppImage client on my Ubuntu 16.04 machine. It works OK and has good support for the "I want that Nextcloud folder synced with this local folder" use case, once I'd deleted the initial unhelpful config which seemed to assume I wanted everything synced (sunc?).

I installed the client again using the PPA for Ubuntu 17.10 and that worked fine,too.

I installed the Android app, and that looks to be working ok too, although it does spend a lot of its time with various 'loading' animations running with no indication of what is happening.

On all of these, the login was really slow - like 20-30s slow. I'm not sure what that's about.

I then thought that I'd install a headless/CLI client, but wait! There isn't one! I found lots of posts on forums and Stack Exchange asking about this, with myriad different third party solutions offered. This surprised me - surely the sync code is abstract from the UI...? Aparently not. But all the replies to these posts seemed to be a bit bemused, like "why would you want that?".

Why would you want a headless sync client?

I think the answer to this lies in the a fact I'd missed: Nextcloud offers a full WebDAV server as part of what it does. I'd come across this a few times in the past - way back - but never really found a use for it. It's an extension to the HTTP protocol for editing files remotely and it has wide support in various OSes.

So if you want to access some directory on a headless server you can mount it in a local dir via WebDAV. Because all changes are sent through Nextcloud, it handles the sync with the main store and then any other clients.

I tried Gnome's GVFS (via Nemo) and the kernel/system driven davfs2. The endpoint is

https://yourserver.com/path/to/nextcloud/remote.php/dav/files/your-user/directory

GVFS worked but seems hideously slow. Especially if you open a terminal in its directory; opening a 100B text file in vim took about a minute(!) and editing was just as slow. Probably vim is creating temporary cache file there, but still... A no-go. Oh, of course this was not headless, but I wanted to test the WebDAV performance.

But davfs2, though odd to set up (setuid, fstab and local user secrets), seems to work quite well; at an acceptable speed on the commandline. For my uses, this will suffice instead of a headless sync daemon.

I'm going to continue trying it out and see how it performs. I'm sad to leave Seafile which has been pretty solid and very fast, but I'm keen to see where I can go with Nextcloud - syncing calendars and contacts is appealing as well as the chat (although I'm a fan of jitsi for that).

Encryption

Nextcloud offers encryption but it doesn't seem very sure about it! I'm going to be trying GoCryptFs with it, which seems to be like EncFs but without the massive vulnerability, and like CryFs but already stable (and possibly faster/more space efficient).

How have you got on with any of this? Drop me a comment.

Add new comment