Cloudron Forum

@nebulon I confirmed that fixed the broken images issue in Slack! Thank you!

Since 3.26.2, Metabase stopped rendering chart and table images, so alerts and dashboard subscriptions fail for both Slack and email. Depending on where you look, it shows up as one of these:

Error registering fonts: Metabase will not be able to send Pulses. This is a known issue with certain JVMs.

or

Could not initialize class sun.awt.X11FontManager

These are both the same failure. The first is what Metabase logs the first time Java's font system fails in a running process; the second is what Java reports on later attempts. It's also been reported for email pulses in 16050.

Timeline: Our Slack alerts worked correctly on 3.26.1 and failed every day after the auto-update to 3.26.2. (I've reproduced it on 3.27.1 on a staging server.)

Root cause: The package moved to cloudron/base:6.0.0 in 3.26.2 (commit 7f36d6a5). Running a font call directly against the 3.27.1 image (in a throwaway container, outside Cloudron) shows the underlying error, which Metabase's log message hides:

Please install the openjdk-*-jre package or recommended packages for openjdk-*-jre-headless.
UnsatisfiedLinkError: /usr/lib/jvm/java-21-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file: No such file or directory

On Ubuntu, libharfbuzz0b is only a recommended package for openjdk-21-jre-headless, and it isn't in the new image. Presumably the old base image supplied it.

Verified fix: installing libharfbuzz0b in the same throwaway container makes Java's font system initialize normally (it finds 8 font families, where before it threw the error above). Installing fontconfig alone didn't help, and neither would /tmp permission or fc-cache changes, since it's a missing library rather than a font cache issue. Suggested Dockerfile change:

apt-get install -y openjdk-21-jre-headless libharfbuzz0b

The test I used:

IMG=$(sudo docker ps --format '{{.Image}}' | grep -i metabase | head -1)
sudo docker run --rm --entrypoint bash "$IMG" -c '
  cd /app/code
  T="(println :font-families (count (.getAvailableFontFamilyNames (java.awt.GraphicsEnvironment/getLocalGraphicsEnvironment))))"
  java -Djava.awt.headless=true -cp metabase.jar clojure.main -e "$T" 2>&1 | tail -n 8
  apt-get update -qq && apt-get install -y -qq libharfbuzz0b >/dev/null 2>&1
  java -Djava.awt.headless=true -cp metabase.jar clojure.main -e "$T" 2>&1 | tail -n 8'

@girish It may also be worth checking other Java-based apps on base 6.0.0 that use the headless JRE for image or PDF rendering, since they could hit the same thing.

Thank you!

@james Understood. For situations like these, is posting on this public forum still preferred over email to support@ or security@?

Same drill as before, but with a new minimum target release...

The downloads below include the minimum safe release for each Metabase version.
 
63
0.63.10
Docker image: metabase/metabase:v0.63.10
Download the JAR here: https://downloads.metabase.com/v0.63.10/metabase.jar

There is not yet a web link documenting this, so I'd recommend reaching out to help@metabase.com if you want independent first-party confirmation on this.

In case this is useful, I saw the Cloudron app update as being available yesterday and successfully updated. “About Metabase” (in app) reports 0.63.5 but the Cloudron Info tab still says “Metabase 0.63.2.7”.

@joseph The CEO of Metabase (not my company’s CEO) sent an email out to their email list. I sent a response to help@metabase.com and they replied immediately to confirm. I’d recommend reaching out to them to confirm. I’ll forward the full email to the Cloudron email account.

@luckow Found it here: https://hub.docker.com/r/metabase/metabase/tags?name=v0.63.5

@luckow I emailed Metabase to ask about the missing release.

Notification email came from company CEO sent out earlier this morning. I tried to upload a PDF of the email but can't upload PDF to this forum.

Until then, the recommended temporary workaround is for users to block the affected endpoint (/api/session/reset_password).

Metabase posted a security advisory today about a zero-day vulnerability giving access to admin accounts. Self-hosted users running Metabase 63 prior to 0.63.5 are vulnerable. I went to update to v0.63.5, and see that it isn't available yet on Cloudron. Requesting an expedited build.

We've seen inconsistent email delivery even on the latest release, which I believe was due to issues specific to Google Calendar (our primary calendar service.) I filed an Issue and I saw a few PRs referencing this with a fix, but nothing was merged. Even if it had been merged, there hasn't been a new release issued on this repo in almost three months (down from multiple per week prior to the strategy change.) Hope to see it revived, but not counting on it.

I noticed that they haven't issued a new release since March 1, where they were previously cutting releases every few days. Looks like they are still merging PRs into calcom:main, but unclear when that will turn into a new release. Any idea who is managing the release process for the repo?

Thanks, @girish!

@joseph I'll share that with them.

Metabase posted this security advisory today: Authenticated users are able to retrieve sensitive information from a Metabase instance, including database access credentials. I went to update to v0.58.7, and see that it isn't available yet on Cloudron. Wanted to request an expedited build.

From my read of the security advisory, disabling outbound email is a sufficient workaround until the new build is installed. I've done this by providing Metabase with invalid SMTP credentials in env.sh

Got it. Thank you.

We recently ran a load test of our systems, and saw something a bit surprising with Etherpad. Under significant load, the CPU utilization maxed out far below the "Max CPU" line set based on the CPU limit set in the Resources tab. Is possible that the Etherpad app (or Cloudron) isn't taking into account the number of cores available, as described in the docs?

When will this auto-update on Cloudron? We'll all need some time to work through the full list of breaking changes (https://docs.n8n.io/2-0-breaking-changes/) before then.

Sorry. bash wasn't supposed to be there. Failed attempt to format the markdown code block.

Wanted to share a working solution, lightly adapted for Cloudron from Github issue comment referenced above:

1. Enter Recovery Mode
2. On the app's terminal: sqlite3 /app/code/data/kuma.db "DELETE FROM setting WHERE key = 'migrateAggregateTableState';"
3. Exit Recovery Mode