Cloudron Forum

@girish In the meantime there were already several official, stable releases of statping-ng. The last one was 6 days ago (v0.90.80)
cfr this link.

So I suppose there is no reason anymore to stay with the original statping (for which the latest version was released in december 2020) ?

Ok, so I was correct when I said I seemed to remember there are some limitations with CF proxy and subdomains in the free plan.
When trying to open a ticket with CF regarding this issue I was pointed to the following link on their community:
https://community.cloudflare.com/t/subdomain-too-deep/81872

The certificates available with the free account (universal certificates) cover only one level of subdomains so my.domain.tld is covered, but my.sub.domain.tld isn't.

According to this thread DoT support was added in v1.2.0 of the AdGuard package (with Cloudron 6.2).

The Cloudron package documentation however still mentions that DoT is "not yet supported"

Therefore I decided to just try it out and after some fiddling with OpenWRT and stubby in particular I was able to get DoT working.

So I guess Cloudron's AdGuard documentation can use some extra love regarding DNS configuration

@girish I see, but I wouldn't expect any solutions from the old, abandoned ticket Maybe you can open a new ticket at statping-ng?

I noticed similar issues since the update to Cloudron 8, but in my case it was caused by the fact that the backup storage wasn't mounted correctly.
After clicking the "remount storage" button this was fixed and backups started working again.

I'm using sshfs and had this issue on 2 Cloudrons.
Maybe there is a general regression in the update procedure that causes the backup storage location to be in an unmounted state, resulting in failed backups?

@girish hmmm, I see, but imagine the following scenario:

Our clients come to us for developing a new Wordpress website and obviously they also want an integrated email system so they can send and receive mails for that website and probably they also want to see some analytics.
So we set up a separate cloudron for such client and install Wordpress for the website, SOGo (or one of the other webmail apps) for the email and Ackee for the analytics.

This means the cloudron is dedicated to the client and therefore the trusting factor is there since the client is the only party that makes use of the cloudron and its apps.

However, our clients aren't interested in administering the cloudron themselves so we will manage it for them. But they do want to be able to add extra email addresses when needed.
So the client will get the mail manager role while we are the admin of the system. In this scenario it doesn't make sense - and isn't even desirable - that the client can see our admin user.

So while I definitely understand your explanation, I hope you can see my point as well

NetCup can't be held responsible for the reputation of the ip address, it's simply a result of what their users have done with that ip address.
And that's something you have to keep in mind when buying servers from any provider, not only NetCup.
But that doesn't mean you can't do anything about it. In fact there is a good chance you can revert it back to a clean state just by taking the correct actions.

As marcusquinn says, Hetzner is very good indeed, but their ip's aren't always clean either. They might be on some blacklists or even blocked alltogether by some parties.
I had a similar situation myself where the ip of our mailserver was blocked by Microsoft and as a result none of our emails could be delivered to microsoft addresses (hotmail, outlook, office365, ...)

BUT: I contacted MS and explained the situation. After providing the necessary info / proof of ownership of the ip, they delisted the ip address and everything is fine since then.

After Nextcloud was automatically upgraded from v23.0.2 to v23.0.3 we started getting issues with up- and downloading of files and even opening of files in the browser.
We're using server-side encryption and a Hetzner storage box over sshfs for the data dir.
Further investigation learned that there was an issue with the encryption/decryption on the server.

The exact error we got was:

Encryption not ready: multikeydecrypt with share key failed:error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs decoding error

Apparently some of the keys were changed in our data dir (the mounted external storage). Luckily we found older, correct keys in the original data dir of the cloudron app (i.e. inside yellowtent).
After replacing the keys on the mounted storage with the older keys from the original data dir everything started working again.

Since there are a lot of encryption related tickets in the Nextcloud repository I mentioned my issue and resolution as a response on one of the still open, relevant issues: https://github.com/nextcloud/server/issues/8349.

But I'm also reporting it here in case it's related to the cloudron packaging and/or someone else here is experiencing similar issues.

@girish since PHP 8.1 isn't supported anymore for almost 6 months now, aren't there any plans yet to upgrade to 8.2 or higher? Also some Nextcloud plugins require at least 8.2 in the meantime.
So both for security reasons and support reasons it's recommended to have at least v8.2.

Earlier this week Umami was still working fine, but today I noticed I couldn't access it anymore.
In the Cloudron logs there were a lot of errors related to yarn.
I tried restoring to several older backup versions, but they all resulted in the same errors.
Also updating to newer Umami versions didn't help.

Since the host was still running Ubuntu 20.04 I decided to update to Ubuntu 22.04 as explained in the docs.
Unfortunately there were several issues during the upgrade process (rebuilding the containers hanged for several hours, nginx couldn't start because config file was missing, ...) but in the end I got everything up and running again... except Umami.

So I decided to again restore to an older backup from several weeks ago, a point in time I'm sure it was working fine, but still the app didn't start.
Then I updated again, version after version, to the most recent version 2.11.2 (package version 3.11.2) but still it won't start.

I have the impression that the cause might be that the database isn't migrated correctly from v1 to v2, but I have no clue how I can verify and/or fix this manually.

Here are the relevant log entries:

Apr 25 22:19:00 box:apptask startApp: starting container
Apr 25 22:19:00 box:tasks update 7264: {"percent":90,"message":"Configuring reverse proxy"}
Apr 25 22:19:00 ==> Changing ownership
Apr 25 22:19:00 box:tasks update 7264: {"percent":100,"message":"Done"}
Apr 25 22:19:00 box:taskworker Task took 87.51 seconds
Apr 25 22:19:00 box:tasks setCompleted - 7264: {"result":null,"error":null}
Apr 25 22:19:00 box:tasks update 7264: {"percent":100,"result":null,"error":null}
Apr 25 22:19:01 NOTICE: extension "pgcrypto" already exists, skipping
Apr 25 22:19:01 CREATE EXTENSION
Apr 25 22:19:01 => Running build script that generates the migrations
Apr 25 22:19:01 yarn run v1.22.19
Apr 25 22:19:01 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable. <30>1 2024-04-25T20:19:01Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:01 $ npm-run-all check-env build-db check-db build-tracker build-geo build-app
Apr 25 22:19:01 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:01 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:01 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:01 $ node scripts/check-env.js
Apr 25 22:19:01 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:02 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:02 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:02 $ npm-run-all copy-db-files build-db-client
Apr 25 22:19:02 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:02 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable. <30>1 2024-04-25T20:19:02Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:02 $ node scripts/copy-db-files.js
Apr 25 22:19:02 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:02 Database type detected: postgresql
Apr 25 22:19:02 Copied /app/code/db/postgresql to /app/code/prisma
Apr 25 22:19:03 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:03 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:03 $ prisma generate
Apr 25 22:19:03 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:03 Prisma schema loaded from prisma/schema.prisma
Apr 25 22:19:04 <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ✔ Generated Prisma Client (v5.12.1) to ./node_modules/@prisma/client in 219ms <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - Start using Prisma Client in Node.js (See: https://pris.ly/d/client) <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - import { PrismaClient } from '@prisma/client' <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - const prisma = new PrismaClient() <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate)
Apr 25 22:19:04 ``` <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - import { PrismaClient } from '@prisma/client/edge' <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - const prisma = new PrismaClient() <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - See other ways of importing Prisma Client: http://pris.ly/d/importing-client <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ┌────────────────────────────────────────────────────────────────┐ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Supercharge your Prisma Client with global database caching, │ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ scalable connection pooling and real-time database events. │ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Explore Prisma Accelerate: https://pris.ly/cli/-accelerate │ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Explore Prisma Pulse: https://pris.ly/cli/-pulse │ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - └────────────────────────────────────────────────────────────────┘ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 -
Apr 25 22:19:05 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable. <30>1 2024-04-25T20:19:05Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:05 $ node scripts/check-db.js
Apr 25 22:19:05 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:05 ✓ DATABASE_URL is defined.
Apr 25 22:19:05 ✓ Database connection successful.
Apr 25 22:19:05 ✓ Database version check successful.
Apr 25 22:19:05 ✗ Umami v1 tables detected. For how to upgrade from v1 to v2 go to https://umami.is/docs/migrate-v1-v2.
Apr 25 22:19:05 error Command failed with exit code 1.
Apr 25 22:19:05 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Apr 25 22:19:05 ERROR: "check-db" exited with 1.
Apr 25 22:19:05 error Command failed with exit code 1.
Apr 25 22:19:05 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Apr 25 22:19:06 ==> Changing ownership
Apr 25 22:19:06 NOTICE: extension "pgcrypto" already exists, skipping <30>1 2024-04-25T20:19:06Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - CREATE EXTENSION
Apr 25 22:19:06 => Running build script that generates the migrations
Apr 25 22:19:06 yarn run v1.22.19
Apr 25 22:19:06 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:06 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:06 $ npm-run-all check-env build-db check-db build-tracker build-geo build-app
Apr 25 22:19:06 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:07 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:07 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:07 $ node scripts/check-env.js
Apr 25 22:19:07 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:07 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:07 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:07 $ npm-run-all copy-db-files build-db-client
Apr 25 22:19:07 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:07 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:07 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:08 $ node scripts/copy-db-files.js
Apr 25 22:19:08 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:08 Database type detected: postgresql
Apr 25 22:19:08 Copied /app/code/db/postgresql to /app/code/prisma
Apr 25 22:19:08 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:08 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:08 $ prisma generate
Apr 25 22:19:08 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:09 Prisma schema loaded from prisma/schema.prisma
Apr 25 22:19:09 <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ✔ Generated Prisma Client (v5.12.1) to ./node_modules/@prisma/client in 207ms <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - Start using Prisma Client in Node.js (See: https://pris.ly/d/client) <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - import { PrismaClient } from '@prisma/client' <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - const prisma = new PrismaClient() <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ```
Apr 25 22:19:09 or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate) <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - import { PrismaClient } from '@prisma/client/edge' <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - const prisma = new PrismaClient() <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - See other ways of importing Prisma Client: http://pris.ly/d/importing-client <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ┌────────────────────────────────────────────────────────────────┐ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Supercharge your Prisma Client with global database caching, │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ scalable connection pooling and real-time database events. │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Explore Prisma Accelerate: https://pris.ly/cli/-accelerate │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Explore Prisma Pulse: https://pris.ly/cli/-pulse │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - └────────────────────────────────────────────────────────────────┘ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 -
Apr 25 22:19:09 ┌─────────────────────────────────────────────────────────┐ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Update available 5.12.1 -> 5.13.0 │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Run the following to update │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ yarn add --dev prisma@latest │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ yarn add @prisma/client@latest │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - └─────────────────────────────────────────────────────────┘
Apr 25 22:19:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.182:3000
Apr 25 22:19:10 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:10 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:10 $ node scripts/check-db.js
Apr 25 22:19:10 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:10 ✓ DATABASE_URL is defined.
Apr 25 22:19:10 ✓ Database connection successful.
Apr 25 22:19:10 ✓ Database version check successful.
Apr 25 22:19:10 ✗ Umami v1 tables detected. For how to upgrade from v1 to v2 go to https://umami.is/docs/migrate-v1-v2.
Apr 25 22:19:10 error Command failed with exit code 1.
Apr 25 22:19:10 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Apr 25 22:19:10 ERROR: "check-db" exited with 1.
Apr 25 22:19:10 error Command failed with exit code 1.
Apr 25 22:19:10 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

How can I get Umami up and running again?

@girish That definitely sounds like an interesting solution, except that in my use case it's not (entirely) related to automation / programmatic access. So I guess it will also need some UI changes.

Oh, and of course you first have to install davfs2.
This can be done with the following command

sudo apt install davfs2

And we're up and running again!
Thanks again @girish , without your help I wouldn't be able to get it running again.

@girish actually both.

Visually, because it doesn't make sense to show admin users to mail managers when they can't do anything with them.

But also security wise because in my opinion users with a lower access role (in this case mail managers) shouldn't know any (sensitive) details about users with a higher role (in this case admins), e.g. username, email address, ...
We all know passwords shouldn't be reused for different accounts/logins but I'm sure usernames are and therefore I think it's better to not show such data to others when that data isn't relevant for them.

Is it possible to use a single domain, let's say example.com, with 2 (or more) cloudrons?

The use case would be to host multiple applications for the same company each on their own server, e.g. websites on one server and forum and mail on another server.

Note: I'm new to Cloudron and I really like it so far, but I'm having some specific use cases and it's not clear to me whether Cloudron is a good fit for them.

@Neluser

If you create the directory /mnt/mynextcloud and then put the following line in your /etc/fstab

https://<fqdn-of-your-nextcloud>/remote.php/dav/files/<your-username>/ /mnt/mynextcloud davfs defaults,uid=1000,gid=100,_netdev,auto        0       0

You should be able to store your backups in your nextcloud.
Automatically after reboot or manually with this command:

sudo mount /mnt/mynextcloud

Note 1: you have to replace the values between <> with the correct values for your nextcloud instance and also make sure you use the correct uid and gid.

Note 2: I won't recommend this for reliable backups as it can be really slow and, well, just unreliable.

@girish that sounds as being the same issue indeed.
So if I understand correctly you already know what the issue is and how to fix it and now it's just a matter of finding some time to actually implement it

@girish Thanks, now I managed to migrate the existing installation with the latest Matomo app package.
It was really straightforward!

@girish actually we have similar use cases.

First of all sender/ip reputation. Some apps send emails in bulk and/or to unverified email addresses while others only send transactional emails to known/verified addresses. Therefore we want to use different email servers/systems for them.

In addition, some apps use email templates built within the mail service and therefore need to send out emails via that particular service, while other apps don't need to / shouldn't send via that service.
The same for newsletters: they have to be sent via a specific service.

Great to hear you implemented this functionality already!

@msbt Hey, yes I was lucky that I kept the original data.
But if you have backups - which I hope you do - you can probably recover the correct keys from those backups
Thing is that you should only restore the keys and nothing else from the backups, otherwise you might get more trouble than you currently have