Continuing with my journey to replace publicly hosted cloud services with self-hosted solutions. One of the nice developments of the recent years are services like Dropbox or Google Drive, which really simplify some use cases. For example, in my own workflow I mainly use these services to a) synchronize unix configuration files, b) synchronize some random temp files I need on several computers or which I need from my phone (I am usually too lazy to get a cable), c) for easy sharing of photos or other files, and d) for synchronizing my Lightroom catalogue across devices, a quite heavy task because of the monolithic sqlite file with > 1 GB. There have only been a few cases where I actually used a shared folder for collaborative work. Computer scientists have better tools for such jobs. ;) So my need for something that is really accepted by many users is again questionable. Hence, I could easily search for a self-hosted solution without many drawbacks.

The first solution I tested was ownCloud. My experiences weren’t too good. Especially, because I was completely unable to manually compile the client on my work computer. After endless tries I finally ended up with a launchable version which, however, didn’t synchronize at all. Some more web-browsing later with endless remarks about the bad support and many open issues I decided against ownCloud.

The solution I ended with is Seafile, a not so well known open source solution with some Chinese developers and good support and issue response times. People might be suspicious because of the origins, but so far I couldn’t find any obvious security issues and things work quite well.

For my setup I followed the installation instructions on the Github wiki using the pre-compiled packages. I am operating Seafile on a subfolder of an SSL-enabled subdomain by using apache as a proxy. Actually, all required information how to set up this configuration can be found on the wiki with some browsing. Things could be better described, but I can also imagine much more horrifying installation instructions.

After installing the Seafile server and adding a user account clients can connect to the server and synchronize multiple libraries. This is a nice concept not directly available in Dropbox etc. Each library is a folder structure with separate settings for the kind of history that is maintained and the ability to enable client-side encryption. Moreover, libraries are the atomic unit that can be shared between users on the same server. E.g. in my setup I created a library for sharing files with others where I completely disabled the history feature and another one for the config files where I preserve a few revisions of history. Across the different collections,  Seafile implements a de-duplication strategy to save server-side storage space. Clients exist for all major operating systems (including a console-based daemon for linux) and also for Android.

Seafile webinterface screenshot

The different libraries I use as displayed in the web interface.

My experiences with Seafile are quite good so far and most things work well. The following issues are the once I noticed and that could be improved.

  • The Android client sometimes silently refuses to upload a file. I could not find out in which cases this happens.
  • There is no option to permanently synchronize single files to an Android device and keep them updated.
  • Desktop clients work flawlessly. The only thing I noticed is that the de-duplication could be used better also to determine what to upload  and what not to. In the case of my 1.x GB Lightroom catalog file, uploads take much longer than with Dropbox and afterwards the size on the server didn’t increase as much as data was uploaded. My impression is that this behavior has been improved with one of the recent client updates, but still the performance of Dropbox is not reached here.
  • Server administrators have to perform a manual garbage collection task from time to time. Otherwise the storage requirements on the server will grow indefinitely. This is kind of annoying despite the explanation why this is required.
  • Clients are still hard to compile. The situation is a bit better than for ownCloud but still many uncommon libraries with differing build systems are required.
  • I didn’t do a server-side update, but I suspect it will be some reading and manual work.