Help with getting Caddy working with Nextcloud and Collabra

Hi there,

Thank you for your guide. It really helps to deploy caddy with nextcloud and collabora. However, I do have a small issue with collabora.

First, I don’t use a frontend or backend scenario. I only have one Caddy instance, that points to my domain and forwards the requests.

I went through the checking steps you mentioned above, and one step doesn’t work well. When I try accessing https://nextcloud.wonkypaw.org/loleaflet/dist/admin/admin.html, I am getting a 400 error.

Looking at the collabora docker logs I see the below error. For some reason, it doesn’t recognise my domain.

full URI: /loleaflet/dist/admin/admin.html| wsd/COOLWSD.cpp:2818
wsd-00001-00040 2021-12-29 18:38:19.161539 +0000 [ websrv_poll ] ERR  Unknown resource: /loleaflet/dist/admin/admin.html G, host: nextcloud.wonkypaw.org, path: 4

Below is my caddy configuration for nextcloud:

# Nextcloud and Collabora
nextcloud.wonkypaw.org {
	encode gzip
	@collabora {
		path /loleaflet/* # Loleaflet is the client part of LibreOffice Online
		path /hosting/discovery # WOPI discovery URL
		path /hosting/capabilities # Show capabilities as json
		path /lool/* # Main websocket, uploads/downloads, presentations
	}

	reverse_proxy @collabora https://127.0.0.1:9980 {
		header_up Host "nextcloud.wonkypaw.org"
		transport http {
			tls_insecure_skip_verify
		}
	}

	tls {
		dns cloudflare {env.CLOUDFLARE_API_TOKEN}
	}

	file_server
	root * /var/www/html

	php_fastcgi 127.0.0.1:9080 {
		env front_controller_active true # Remove index.php form url
	}

	reverse_proxy http://127.0.0.1:9080 {
		header_up X-Forwarded-Host {host}
	}

	header {
		Strict-Transport-Security max-age=31536000; # enable HSTS
	}

	# .htaccess / data / config / ... shouldn't be accessible from outside
	@forbidden {
		path /.htaccess
		path /data/*
		path /config/*
		path /db_structure
		path /.xml
		path /README
		path /3rdparty/*
		path /lib/*
		path /templates/*
		path /occ
		path /console.php
	}

	respond @forbidden 404
}

What am I doing wrong? I only added the TSL configuration and reverse proxy for my nextcloud instance. The rest of the configuration stays the same as yours.

The docker-compose is the same, I deploy all three containers with the same docker-compose file.

Thank you!

Hi,

I manage to fix the issue with collabora and nextcloud. Now I can open documents within nextcloud.

You can close this post btw.

If anyone is interested in how to deploy Nextcloud with Collabora behind caddy this is my final Caddy file configuration. The below configuration is for NextCloud 23+ version.

# Collabora
collabora.runner {
	encode gzip zstd
	@collabora {
		path /browser/* # Browser is the client part of LibreOffice Online
		path /hosting/discovery # WOPI discovery URL
		path /hosting/capabilities # Show capabilities as json
		path /cool/* # Main websocket, uploads/downloads, presentations and admin
	}

	reverse_proxy @collabora https://127.0.0.1:9980 {
		header_up Host {host}
		header_up Connection "Upgrade"
		header_up Upgrade websocket
		transport http {
			tls_insecure_skip_verify
		}
	}

	tls {
		dns cloudflare {env.CLOUDFLARE_API_TOKEN}
	}

	header {
		Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # enable HSTS
	}
}
# NextCloud
nextcloud.runner{
	header {
		Referrer-Policy "no-referre" always;
		Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
		X-XSS-Protection "1; mode=block"
	}

	reverse_proxy http://127.0.0.1:9080 {
		header_up Host {host}
		header_up X-Forwarded-Host {host}
		header_up X-Content-Type-Options "nosniff" always;
		header_up X-Robots-Tag "none" always;
		header_up X-Frame-Options "SAMEORIGIN" always;
		header_up X-Download-Options "noopen" always;
		header_up X-Permitted-Cross-Domain-Policies "none" always;
	}

	encode gzip zstd
	tls {
		dns cloudflare {env.CLOUDFLARE_API_TOKEN}
	}

	root * /var/www/html
	file_server

	php_fastcgi 127.0.0.1:9080 {
		env front_controller_active true # Remove index.php form url
	}

	redir /.well-known/carddav /remote.php/carddav 301
	redir /.well-known/caldav /remote.php/caldav 301
	# .htaccess / data / config / ... shouldn't be accessible from outside
	@forbidden {
		path /.htaccess
		path /data/*
		path /config/*
		path /db_structure
		path /.xml
		path /README
		path /3rdparty/*
		path /lib/*
		path /templates/*
		path /occ
		path /console.php
	}

	respond @forbidden 404
}

I followed [ Caddy reverse proxy + Nextcloud + Collabora + Bitwarden_rs with local HTTPS](Caddy reverse proxy + Nextcloud + Collabora + Bitwarden_rs with local HTTPS) tutorial for reference.

In the latest version of NC they renamed two paths, loleaflet was renamed to browser and lool was renamed to cool.

For docker-compose configuration follow the tutorial above, nothing much changed there.

If it happens that Collabora is not able to resolve the DNS of your domain add those entries inside the /etc/hosts file where you are running the server. In my case, I added two entries pointing to my server IP where the docker instances are running. I wasn’t expecting this behaviour to happen, since I am running my own Pihole DNS server. These records are already in pihole.

Docker is also configured to use my Pihole DNS server to resolve names. But for some weird reason is not able to resolve it.

Regards,

3 Likes

If you encounter issues to login in nextcloud follow this guide:

https://techoverflow.net/2020/02/09/how-to-fix-nextcloud-refused-to-send-form-data-to-login-v2-grant-because-it-violates-the-following-content-security-policy-directive-form-action-self/

I spotted a typo in your config:

		Referrer-Policy "no-referre" always;

You’re missing an r at the end of no-referrer.

Also: does NextCloud + Caddy work for you as expected?
I see major performance issues to the point, that it becomes basically unusable due to 3896 - Frequent hangs when using http/2 push and it seems there’s no way to disable HTTP/2 (to use only HTTP1.1) in Caddy V2 (in Caddy V1, -http2=false used to work).

The only major difference between our setups: I’m using PHP-FPM’s AF_UNIX socket instead of AF_INET on 127.0.0.1.

Hey there,

I just finished deploying nextcloud, so far I don’t see any issues with performance. It works as expected.

I am using the default docker image, which from what I understood it has apache server behind it.

I tried using the FPM image but I didn’t have any luck with it. I kept getting error 502 when I was trying to log in. I am new to this setup btw so if I talk crap please let me know :slight_smile:

Thanks for the typo, I tried editing the post but I can’t do it anymore. Weird!

Thanks for sharing the post, I will read it and keep an eye on my NextCloud instance. If I encounter performance issues I will let you know.

What version of NextCloud do you use?

I’m using 23.0.0 on NixOS, PHP-FPM 8.0.13.

I might give a non-FPM setup a try to see whether it behaves differently.
Right now, I’m about to switch from php_fastcgi to reverse_proxy to see if this helps in any way or whether the problem is not so much about the backend connection, but the HTTP/2 bug actually is about the Client <> Caddy connection.

My setup is Docker with Rancher server 1.6 to manage my containers. Good luck with your migration, hopefully, it would be better.

Speaking of performance. I configured the client to connect to my server, and because I am using virtual files it takes a while to scan all my files from SMB share. I did notice that for about 2-3mins the client connection dropped. I am using OpenSuse TW, the virtual files feature is still under development in Linux. Maybe this has nothing to do with the server and is more about the client. I will keep an eye and let you know.

Regards,

Hi,

I want to ask you a question. Is Nextcloud always slow on the first initial sync?

I am synching around 5.6GB of data and it took like 3hs to do that. Whereas, when I use something like resilioSync it takes minutes. I am using everything inside the local network, at 1GB speed. So there’s no external connectivity happening or stuff like that.

This thing kind of puts me off. Is this what you were talking about performance?

Regards,

I referred mostly to the web UI’s/API performance which seems to have quite some room for improvement.

Can’t really speak in terms of file sync performance, as I use it only for a few smaller files so far - I only recently synced around 10GiB of photos for a few functional tests and while I didn’t closely monitor it, the performance seamed reasonable for a cloud sync (non-local network).

Thanks for your input.

For me, it seems synching internally was slow on the first initial setup. Maybe this is how nextcloud works, it needs to scan all the files first before syncing them.

Thanks anyway!

This topic was automatically closed after 29 days. New replies are no longer allowed.