How to make NextCloud the root app for lighttpd

Hi everyone!

Love Diet Pi! Such low memory footprint and running processes. It’s the distro of choice for all my SBC needs! So thanks to all who make this possible.

I have a problem I hope someone might know the answer to. Currently I have nextcloud installed and working when pointing to /nextcloud however I’d like nextcloud to be accessible just using the root

Or even better, have nextcloud on it’s own port such as

What do I need to do to the lighttpd configuration to make either of these scenarios happen?

In /etc/lighttpd/lighttpd.conf you have the line

server.document-root        = "/var/www"

You would need to change this line, but you also have to adjust the paths in /etc/lighttpd/conf-available/99-dietpi-nextcloud.conf and activate the modified config. Also anything else in /var/www is then not accesible anymore, since the root would be /var/www/nextcloud.

For the port change, you could maybe do something like:

  # multiple sockets
  $SERVER["socket"] == ":8080" {
    server.document-root = "/var/www/nextcloud" 
But you have also adjust again some stuff in `/etc/lighttpd/conf-available/99-dietpi-nextcloud.conf` since only adding this to the config gives a 404 error.

[Edit]: But it seems more changes somewhere else are necessary, since only changing this gives a 404 error.

Do you use nextcloud only inside your LAN? Do you use any domains to access nextcloud from the internet?

what should be the benefit of having lighttpd web server running on a different port?

OK thanks for your help people. I used these bits of info to start a search which led me to a solution which I’ll post for the next person.

Since my nextcloud will be available on the open web, I went with serving nextcloud on a different port.

In my lighttpd.conf, I added this at the end:

$SERVER["socket"] == ":88" {
	server.document-root = "/var/www/nextcloud/"

Then I made a copy of 99-dietpi-nextcloud.conf and called it 100-dietpi-nextcloud.conf. I did this so that next cloud will still work on the original HTTP address if I ever accessed it.

Then I changed my 100-dietpi-nextcloud.conf to look like this.

$SERVER["socket"] == ":88" {

	# Hardening
	# - Directories
	$HTTP["url"] =~ "^/(build|tests|config|lib|3rdparty|templates|data)($|/)" { url.access-deny = ("") }
	# - Files
	$HTTP["url"] =~ "^/(\.|autotest|occ|issue|indie|db_|console)" { url.access-deny = ("") }
	# - Directory listing
	dir-listing.activate = "disable"
	# - Security and cache control headers for static resources
	$HTTP["url"] =~ "\.(css|js|svg|gif|png|jpg|ico|wasm|tflite|map|woff2?)$" {
		setenv.add-response-header += (
			"Referrer-Policy" => "no-referrer",
			"X-Content-Type-Options" => "nosniff",
			"X-Download-Options" => "noopen",
			"X-Frame-Options" => "SAMEORIGIN",
			"X-Permitted-Cross-Domain-Policies" => "none",
			"X-Robots-Tag" => "none",
			"X-XSS-Protection" => "1; mode=block",
			"Cache-Control" => "public, max-age=15778463"

Now all is well and working.

1 Like

you don’t use https? You should do if your system is available from internet.

That’s the next thing I need to do for sure.

but this will require again port 80 to be open if you like to use dietpi-letsencrypt because certbot require port 80 to verify your domain.

My router will use port 80 but it will forward internally to 88

1 Like

but there is no gain in security if your router is still using port 80 to have it forward to port 88.

Router uses port 80 and 443, forwards internally to 88 and 444 respectively. Let’s encrypt will still work.

In this case, it doesn’t make sense to move ports of Nextcloud web server. There is 0 benefit related to security as you are still reachable on 80/443 from extern. For the external access it doesn’t matter what internal ports you are using.