Nextcloud

Last updated on Dec 3, 2023

Nextloud logo

I want to write up about some of the stuff that I put together for my Nextcloud instance, but first I have to tell you how is the base set up. So here we go. If you are here, you probably know that you need Nextcloud. I wanted Nextcloud because I wanted to get rid of paid Google services.

Since 25.6.2023 is Nextcloud installed inside the container and some of these settings might be driven by linuxserver team. I will keep most of the settings here.

I installed Nextcloud few years ago and the docker run command definitely looked quite different back then, but here is my current one.

docker run
  -d
  --name='nextcloud'
  --net='proxynet'
  -e TZ="Europe/Prague"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="ClearSky"
  -e HOST_CONTAINERNAME="nextcloud"
  -e 'PUID'='99'
  -e 'PGID'='100'
  -e 'DOCKER_MODS'='linuxserver/mods:universal-package-install'
  -e 'INSTALL_PACKAGES'=''
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='https://[IP]:[PORT:443]/'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/nextcloud-icon.png'
  -p '444:443/tcp'
  -v '/mnt/user/nextcloud':'/data':'rw'
  -v '/mnt/cache/appdata/nextcloud':'/config':'rw'
  -v '/mnt/cache/appdata-cache/Nextcloud/logs':'/config/log':'rw'
  -v '/etc/localtime':'/etc/localtime':'ro'
  -v '/mnt/cache/appdata-cache/Nextcloud/':'/tmp/conf_tmp':'rw' 'lscr.io/linuxserver/nextcloud:latest'

My docker run command

The 'DOCKER MODS' variable allow you to install packages into the container. It is a Linuxserver special, it does not work with every container. If you are interested in some documentation then here you go linuxserver / docker-mods. In the current setup this variable is not utilised further in 'INSTALL PACKAGES' variable but that will change soon.

First volume is the Nextcloud /data volume. When you create a new user its folder structure will be created in this folder. Nextcloud logs are located in here and some of the apps also use this volume.

Second volume is where the container data go. Here you will find php and nginx logs, nginx backend proxy configs a all other configs.

./log
- nginx access and error logs
- php logs
./nginx
- nginx backend proxy confs
- sometimes have to be changed to get rid of warnings in admin settings
./php/
- www2.conf
  - PHP-FPM config
  - sometimes have to be changed to get rid of warining in php logs
- php-local.ini
  - PHP config
  - drives ie. memory limit or maximum upload file size
./www/nextcloud/config/
- config.php
  - config for your Nextcloud instance
  - you will be mostly changing this one

Third volume - /etc/localtime, was an attempt to fix time zone issue which you will hit if you are using Firefox and have turned on some privacy options (mainly the resistance to fingerprinting). Linking this to the container was suggestion that I found somewhere. It is a known issue without a solution so far:

Volumes on appdata-cache

There are two volumes on appdata-cache share. These were created mainly because CA Backup Appdata was failing during backup process. I did not want to stop some of some containers (mainly databases) and Nextcloud was among them. Some files got changed during the backup and the checksum then failed. I solved this by creating a new share in Unraid, which has the same settings as the basic appdata share, and moved some of the problematic files here. These files are usually expendable and are not backed up.

I did not want to stop the container because I was playing around with the Elasticsearch and it was usually running overnight.

Logs

First of "the problematic" files were logs - /config/log. So I diverted these to the appdata-cache share. I can still access them but they do not corrupt my backups.

Big files timeouts

The second volume (/tmp/conf_tmp) on the appdata-cache share contains various temporary folders. I set up those while trying to mitigate a problem with uploading large files.

I am running my Nextcloud instance behind Cloudflare proxy and that proxy has it's own limitations in terms of filesizes and timeouts. Filesizes can be overcome by chunking the large files (Nextcloud Documentation - Chunked file upload). Chunking splits the larger files into chunks and these are then assembled on the server. This assembly can take some time in case of larger files and this is when the fun starts.

Cloudflare proxy can time out during the assembly and you will see an error 504, but that is only for the current window (or view?) because the server did not come back with the result in time. The assembly still continues thought and most of the times finishes fine and you will get your file.

This timeout issue is not resolved for quite some time but it is well known. More on this topic can be found in the following links:

In the documentation you can find some additions to your configs and in the forums then where to put them, or at least that is how I went with it. It did not really help, because it is solving the problem at wrong place. IMO the solution is some kind of a live check between the client and the server that will over come the Cloudflare proxy (and any other proxy basically) time out as somebody pointed out on Github. But I guess that this has some implications so it is not as straightforward as it may looks.

Nextcloud config

The config for your Nextcloud instance lives in /data/www/nextcloud/config. There is also quite exhaustive sample file with the options documented. Some Nextcloud apps fill in the config on their own and some of them will have instructions what to fill in.

My config is not special. There is nothing outstanding and it is quite lonk so I will not post it here. I might dedicate it another post in the future.

nginx configs

There are actually two sets of configs here. One is for the containers backend. That one allows access to the Nextcloud installation and is used to proxy when you access the container's exposed ports. Second set is to access the container from outside. That one is used when the container is accessed from outside. The second works hand in hand with the first.

I will only write about the configs that are changed. There is no point in summarizing something that is stock. Documentation for the configs again lives in the Linuxserver space.

Backend nginx configs

These live in /data/www/nextcloud/config Defaults are available on Github

Sometimes you have to change those when new update is out and you ahve a warning in your Administration - Overview. But lately Linuxserver guys also take care of these. When some of the configs get updated, you will see a notification in the container logs. You can then compare the new *.conf.sample file with your current *.conf and just accept the changes most of the times. 😃

This is now mostly taken care of by linuxserver team.

Frontend nginx configs

Defaults are on Github again

Most notable update updating proxy.conf to get real client IP addresses when running behind Cloudflare proxy.

#Cloudflare
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header CF-Connecting-IP;

updated proxy.conf

The set of IPs can be found here - https://www.cloudflare.com/ips/.

PHP config

These settings are related to, you guessed it, PHP! Sometimes you can hit a memory or max upload file size limit and this is the place to fix it - if you have the resources available.

memory_limit
- This sets memory limit for php. I ended up setting it quite high because of the elasticsearch plugin (or the Recognize plugin?)
upload_max_filesize and post_max_size
- These are related to the largest file you can upload. These limits do not apply to public uploads
upload_tmp_dir
- I moved this temp folder to the appdata-cache share as I mentioned in the Big files timeouts section

Nextcloud is the largest container that I am running so I am giving a lot of resources as you can see in the config.

; Edit this file to override php.ini directives and restart the container

;Time zone
date.timezone = Europe/Prague
;Max memory to run php
memory_limit = 16G

;Max upload size
upload_max_filesize = 16G
post_max_size = 16G
;Temp php folder
upload_tmp_dir = /tmp/conf_tmp/php/

updated php-local.ini

Some of the related documentation is already linked above:

Uploading big files > 512MB — Nextcloud latest Administration Manual latest documentation