Setting up a Self-hosted 'Dropbox' Server

server
 
network
 
setup
 
nextcloud
 

Cloud File Synchronization Software was one of the technologies whose concept left me in awe. My very first encounter of it was with Sugarsync. After Sugarsync abandoned us the free users, I jumped around Dropbox, SkyDrive (later renamed to OneDrive), Box trying to maximize on free space, meanwhile also trying out Google Drive and 百度云 from the Chinese Google. Fast-forward a few years, open source solutions like NextCloud (branched off OwnCloud) is gaining lots of traction and its community is as active as ever.

Why ‘NextCloud’?

Self hosting open source solutions has the benefits of:

  • Self control of your own data;
  • Vastly cheaper solution. No monthly fees as long as you have a spare server, access to the Internet and some free time. Your space is only limited by your physical disks space;
  • Fun. A lot of fun.

NextCloud has the largest community out of all open source solutions, and it was forked from OwnCloud when Frank and the core devs left OwnCloud. NextCloud is 100% committed to open source.

Basic Setup

It would be one too many installation guide from me as the community already provides many comprehensive step-by-step tutorials. Instead, I will focus on highlighting the differences between different installations, dependencies and breakdowns of parts.

Both OwnCloud and NextCloud tend to have outdated information on their official documentations, but I have not run into any issues following the ones from DigitalOcean:

The two tutorials above represent two different methods: LAMP stack dependency vs Snap Installation. The former relies on dependencies on Apache Server, MySQL Database, PHP support, etc, while the latter comes with all dependencies in Snap. Both approaches are viable for NextCloud, and other than the two mentioned, installation via Docker Image or Virtual Machine are also popular within the community. My personal favorite is Snap Installation for the following reasons:

  • Comparing to containers/VMs, it runs on bare metal, has no cost for virtualisation and it is more friendly to server optimizations;
  • With Snap handling the dependencies (at a small cost of the disk space), the installation is more succinct (next post we cover its maintainability), more robust (no external dependency) and greatly simplifies the installation process.

Methods aside, I classify the steps into two categories:

1. Installation and Configuration

Depending on the installation method, the first part might include:

  • Bare metal and LAMP dependency: install dependencies; install software; configure dependencies;
  • Snap: install software with Snap;
  • VM: download and installation VM;
  • Docker: download and load image.

Then configure server according to the tutorials.

2. Web and Network

There are mainly two use cases that I can think of:

  1. As a replacement for commercial services (e.g. Dropbox). In this case, user would need access to the server on the public network just like accessing the popular commercial solutions;
  2. Internal testing or having it available within a private network. In this case, user’s access to the server is restricted within the private network.

A few steps to properly set up the web and network:

  1. Obtain a domain name that resolves to the server. Depending on the use case, for #1, a domain name needs to be registered and request the DNS provider map the domain to the server’s address. If not picky about the name, free services like No IP exist; for #2, similar steps need to be taken, except it’s on internal DNS servers of the network.
  2. Sign the SSL certificate. After setting up the domain, create an SSL certificate. Then, for #1, sign the certificate with a Certificate Authority (a popular free choice is Let’s Encrypt); for #2: sign the certificate with own CA and distribute CA to users in the network. Worth mentioning that, a Snap installation greatly facilitates the SSL certificate creation.

Additional Setup

The above setups suffices for a basic setup for a server with Public IP or for a server used inside a private network.

DNS for NAT

Several issues arise with having the Nextcloud server behind a NAT. Namely:

  1. Server is assigned a private IP that is not reachable from the outside of NAT router’s network;
  2. Even with issue#1 resolved, clients need different addresses to reach the server depending on whether they are inside the private network or outside of it.

We discuss the issue and the solutions in a separate post.

The paths provided in the NextCloud official documentation on WebDAV didn’t work on my server, possibly related to my server being upgraded from OwnCloud.

  • From NextCloud documentation:

https://example.com/nextcloud/remote.php/dav/files/USERNAME/

  • From OwnCloud documentation:

https://example.com/owncloud/remote.php/webdav

  • Actual link that worked for my server:

HTTPS: https://example.com/remote.php/webdav
WebDAV: davs://example.com/remote.php/webdav

More Reading

Documents:

Follow up posts:

Stories: