did you set up letsencrypt/certbot in the first place to write files to /usr/local/etc/letsencrypt/live/domain.org/cert.pem
? If so, did you take care to replace domain.org
by the actual domain you are using?
The documentation you linked looks a bit funny in that the first command writes to private key/cert to privkey.pem and cert.pem, but then the second command tries to read in a (likely) certbot-created certificate. I guess if you followed the steps you need to replace usr/local/etc/letsencrypt/live/domain.org/cert.pem
in the second command by the cert.pem created in the first one?
My condolences! Copying the data around may be reasonably straightforward if you can get it out of the snap (it’s just a directory, after all), but I have no idea how the database is setup for it. Good luck nevertheless!
I’d hope for the exact same performance with Docker (or KVM) as on a baremetal host, unless you’re doing userspace networking for ultra-low latency Nextcloud :D (and even that I suppose you could PCI-passthrough the network card?)
No worries :) Let me rephrase the question though - what installation method would you be using if you could?
So far I’m reasonably happy with a baremetal installation, but considering moving it into some kind of VM.
Not using Nextcloud in snap and not sure where I said I was using it inside snap? What installation method are you using at the moment?
I have nextcloud running just fine (with Apache) on a non-443 port. What issue are you seeing exactly? Once your webserver is listening on your port of choice, Nextcloud will show an “untrusted domain” warning if the domain/port have not been set in config.php properly. After that is done, it works perfectly for me.
Previous release had PHP 7.4, new one has 8.2. Nextcloud 24 supports 7.2 - 8.0, 25 supports 7.2 - 8.1 and 26 supports 8.0 - 8.2, which is a bit inconvenient.
To upgrade, I first¹ upgraded Nextcloud to 25, then PHP to 8.2, removed the versioncheck in Nextcloud to accept PHP 8.2 and then upgraded to Nextcloud 26.
Otherwise very smooth - even the usrmerge was absolutely event-free.
¹) of course what I actually did first was upgrade Debian/PHP without checking beforehand and then installing PHP 7.4 from the previous release again.
They could just delete the file to deny you access to your db?