Home cloud server

We have for years desired a self-hosted solution to unify our fragmented data collections in one centralized location. This was the major impetus behind wtfs, for example. Ideally, we wanted a system that was:

• self-hosted
• not overly complicated to install and configure
• easily accessible across our entire infrastructure
• able to share selected contents through a public link
• expandable simply by adding more storage devices

We happened upon our current solution quite by accident while reading 2600. In an article titled “5G Hotspots and Tinc”¹⁾, the author explains that after switching from traditional internet service to a T-Mobile hotspot, they lost access to their home Nextcloud server. They go on to describe how they were able to restore access thanks to tinc. Having never heard of either application before, this piqued our interest. A short burst of research convinced us that this was the solution we sought.

We began the deployment with tinc since we, like the 2600 author, had no control over port forwarding at the installation location. Unfortunately, tinc's configuration parameters had changed in the year and change since the article's publication.

As has been the trend with our recent server operation, we opted to install Nextcloud within Docker using the instructions at nextcloud/docker. In the initial installation, we neglected to enable a persistent volume for the Postgres instance; when we later ran docker-compose down, we lost the entirety of our uploads, plugins, and settings to that point.

Since the server itself is located on our home LAN, we wanted to be able to access it using a local address whenever possible. Nextcloud has a config option called overwritecondaddr that tells it when to overwrite the requested URL. If the page request comes from an address matching the regex in overwritecondaddr, then the server replaces the URL with overwritehost. Unfortunately, the code which performs this check contains a bug that has inexplicably persisted since at least 2017. A relatively minor change to lib/private/AppFramework/Http/Request.php is all that is needed to fix the issue²⁾.

The Nextcloud admin guide's page on NGINX usage³⁾ looks considerably more daunting that the actual process ended up being. The relevant section of our NGINX server definition is included below. This has proven sufficient for even the CalDAV/CardDAV syncing. We also increased client_max_body_size to 100 M for faster uploads.

server {
  server_name PUBLICURL;
  access_log /var/log/nginx/nextcloud.log;
  error_log /var/log/nginx/nextcloud.error.log debug;
  
  client_max_body_size 100M;
  
  # redirect http connections to https
  error_page 497 =301 https://PUBLICURL:8080$request_uri;
  
  location / {
    proxy_set_header     Host $host;
    proxy_set_header     X-Real-IP 10.0.0.1;
    proxy_set_header     X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header     X-Forwarded-Proto $scheme;
    proxy_pass           http://10.0.0.4:8080;
    proxy_read_timeout   90;
  }
  
  listen [::]:8080 ssl ipv6only=on;
  listen 8080 ssl;
}

Once configured properly, operation has been very smooth. Audio/video streaming worked right out of the box, and calendar syncing to Android was easy enough to set up. Navigation does come with a noticeable lag; as far as we can tell, this is due to hardware limitations.