Apart from the silly voice, what happened to maybe waiting a couple hours/days/months before upgrading? Who knows what new bugs this new version introduces.

Did he have to flee by running through a lavender field? (:

They could just delete the file to deny you access to your db?

I’ve never used Jellyfin so pretty sure I’m one of the worst people to ask and I doubt anybody else will see this so far down. If I were you I’d try and have a look at the logs - either the reverse proxy logs (which seem to be really popular these days) or the actual webserver/Jellyfin ones. Those will typically log some errors.

If you get a 404 from Jellyfin then port forwarding is set up correctly (as otherwise you wouldn’t be able to connect to Jellyfin at all). You may be getting a 404 from something else though.

Either that (if you want to use a self-signed cert) or point it at the certbot-created files in /etc? If I understand the jellyfin docs correctly, the second command just translates the usual .pem files into a .pfx file for jellyfin, so should work with any certificate you give to it.

If you’re going to do the latter, you should also add a certbot deploy script to regenerate the .pfx file after a certificate renewel (and possibly restart jellyfin, idk).

Mussten eine geplante Radtour wegen Krankheit absagen, deshalb unerwartet Urlaub in Balkonien. Auch nett. :)

Tja.

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?

Statt nach “Aktiv” nach “Neu” zu sortieren hilft bei mir, etwas mehr Abwechslung hereinzubringen.

Ideal fände ich aber auch eine “gleichberechtigte” Anzeige (je ein Post von jeder Community bis jede abonnierte ebensolche angezeigt wurde, dann wieder ein Post von der ersten etc.). Sonst gehen posts in kleinen Communities doch leicht verloren.

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.

Yeah I was seeing some issues posting to (and even loading from) other instances. Timed my week off quite precisely for this :)

Need to keep The Traditions™ alive :)

Thank you for creating this! :)

It was raining for about 15 minutes earlier. That was nice.