Alas things are no so simple. I just installed Ubuntu 20.04 Server with the Nextcloud option.
On the up side, it worked smoothly and Nextcloud is running fine and dandy.
On the downside, it’s fine and dandy but not complete. Various things are just plain broke and all the searching on-line finds solutions for a non snap installation. Aaargh. I even checked with apt and there is no non snap install offered in the Ubuntu 20 apt repos at all! So it’s not even a trivial option.
Given snap is a “thing” I guess it’s worth upskilling a little. Still it’s frustrating that even snap info on-line is wildly inconsistent and contradictory.
The tips here are a case in point. I love the summary @mactrent wrote, and yet nothing under /snap/nextcloud/current is writable on my system. Moreover the mechanism of the write protection is mysterious as all heck as “ls -l” suggests fine and also with sudo or even logged in a root, no can write.
Which leaves the question, how to tweak Apache settings for example. I for installed as above, and then I tested and I can access it via http://192.168.0.14 (where the servers sit on my LAN), I can access it via http://nextcloud.lan (where that’s a LAN resolved name) and I can access it via http://nextcloud.mydomain.tld (which is the global name that resolves to my server).
I am BTW replacing an existing NextCloudPi install with this one and so the context is stable and long defined and the Nexcloud server sits behind a reverse proxy on an OpenWRT router.
So then I enable SSL:
sudo nextcloud.enable-https lets-encrypt
Now it works fine with https://192.168.0.14 and it works fine with https://nextcloud.lan but https://nextcloud.mydomain.tld produces a 301 redirect to … wait for it … https://nextcloud.mydomain.tld …
How, why? Nothing in the logs. A load of unrelated errors in the logs (related to spreed and ResourceLocator) leaving one with a sour taste regarding the integrity of snap installed Nextcloud … egads, but we digress (and can solve those later), because there is NOTHING in logs about this redirect.
sudo snap set nextcloud mode=debug and still nothing in the logs reported by:
sudo nextcloud.occ log:.
sudo nextcloud.occ config:system:set loglevel --value=0 and still nothing reported when I reload https://nextcloud.mydomain.tld.
Apache is redirecting back to itself is my gut feel. But it is night impossible to diagnose.
So I find this:
in which I see clues but man it’s not lucid, not can I see an Apache access and debug log that shows how it’s evaluating rules … nor can I find a way to configure it.
It’s danged annoying and I’m on edge of tossing it all, and going back to NexcloudPi which while sluggish and crashing a fair bit is configurable and has diagnostics.
The big question is why would Nextcloud redirect to itself in an endless loop when the request comes in via a reverse proxy. It’s not the gateway router (reverse proxy) that’s doing the redirect, it is OpenWRT fully configurable and diagnosable and it’s easy to test empirically, by shutting down Nextcloud (the 301 endless loop changes to 503 Service Unavailable. In short the Reverse porxy is trying to forward the request and getting no response.
What I’d give to be able to configure Apache to produce solid diagnostics here.