I was just emailing my work email to double check I've got my out of office on.

I work at https://communityenergyengland.org (quite a long URL). And my name is Josef Davies-Coates (quite a long name).

When I enter my work email address into the box and it turns into a little blue lozenge, it cuts the end of the email off, making it look like I didn't type it in in full (I did) and just shows up to @communityenergyengl without the and.org.

The full email address ought to be displayed, however long it is.

@timconsidine said:

@daebak see https://forum.cloudron.io/post/131604

But in short: yes, update your Nextcloud ASAP. The update is already out.

@p44 said:

WordPress (Developer) 7.0
Package version
org.wordpress.unmanaged.cloudronapp@4.0.0

You're suffering from something that got me (and others) too - that 4.0.0 release was a mistake. You need to force the update the the newer version with a lower release number using the CLI:

cloudron update --app SITE_LOCATION --appstore-id org.wordpress.unmanaged.cloudronapp --force

@OneTools-Project I don't know. I've stopped all of mine. But you can't update stopped apps, so you have to restarted the again to update them. I'm taking advantage of the Cloudron CLI for the first time to make this process quicker and easier. And Claude just gave me this to restart and then force start all my WordPress apps that were all stuck on a wrong 4.0.0 version number and so weren't able to update:

for a in $(cloudron list | awk '$5=="stopped" && $3=="org.wordpress.unmanaged.cloudronapp@4.0.0" {print $1}'); do cloudron start --app "$a" && cloudron update --app "$a" --appstore-id org.wordpress.unmanaged.cloudronapp@3.17.0 --force; done

@james I think that's meant to be --app?

Also it wasn't just the managed app that was affected, all of my WordPress Developer apps were effected too.

I'm now running this to restart my stopped WordPress sites and then force update them:

for a in $(cloudron list | awk '$5=="stopped" && $3=="org.wordpress.unmanaged.cloudronapp@4.0.0" {print $1}'); do cloudron start --app "$a" && cloudron update --app "$a" --appstore-id org.wordpress.unmanaged.cloudronapp@3.17.0 --force; done

@p44 I don't have the knowledge to know tbh. But it sounds a bit like what more qualified @fbartels described in that other thread.

@privsec follow the announcement thread, but yes, see this list https://forum.cloudron.io/post/131373

I just did what I think is a quite common thing:

I wanted to email someone whose email I couldn't remember (and I guess isn't getting pulled in from Nextcloud because I've taken that offline due to the PHP thing), so I searched my inbox for the most recent email from that person, then hit reply.

But I also changed the subject (because it was about something new), and deleted the email thread chain from the new email. And hit send.

But now the message that I sent is appearing in my inbox and it looks like it comes from who I sent it to! Odd. I think caused by what I did. But again, I think that is a common user story and so likely needs addressing

Sometimes I want to move an email from Cc: in to To: but at present 1) I can't just drag them like I want to be able to, but moreover 2) it doesn't even seem possible to select nor right-click copy them either. So there is no clear easy way of getting an email from one field into another, which is very frustrating.

I've just installed Cloudron CLI and stopped all my PHP apps for good measure (with the help of Claude)

@luckow said:

@jdaviescoates as fas as i know:
2fauth
ampache
bookstack
castopod
dokuwiki
dolibarr
easyappointments
espocrm
firefly-iii
freescout
freshrss
glpi
grav
humhub
invoiceninja
jirafeau
kanboard
kimai
koel
leantime
limesurvey
lychee
matomo
mautic
mediawiki
monica
moodle
nextcloud
omeka-s
opodsync
osticket
piwigo
pixelfed
privatebin
roundcube
rss-bridge
shaarli
snappymail
snipeit
tachyon
tinytinyrss
wallabag
wallos
wordpress-developer
wordpress-managed
xbackbone
yourls

Thanks, I was about to post the same list. Plus LAMP.

@girish said:

grep -A2 'ca-certificates' /var/log/apt/history.log | tail -n

that's missing a number at the end. I went for:

grep -A2 'ca-certificates' /var/log/apt/history.log | tail -n 3

@girish is there a handy list somewhere of which Cloudron packages are PHP?

@romu79230 said:

a genuine Nextcloud backup-and-restore migration between these two Cloudron

For the record this is very easy to do if you do what any decent technical person would do and not let the Cloudron go years out of date.

Update: Now on Cloudron 10.1.5.

The fresh rsync target fixed Nextcloud, but Jellyfin kept failing the integrity check with the same error. I've now tracked that down too, and it isn't just a migration problem.

The new target was created on 24 September, well after the migration. Comparing a full file listing of Jellyfin's live data with its latest rsync backup:

• 1,017 files exist only in the backup (about 18% of the 5,698 files in it)
• 0 files exist only on the server

So nothing is missing, but the backup is full of stale leftovers. All of them are folder.jpg images from data/jellyfin/data/metadata/People/<name>/ folders that no longer exist on the server. Those will mostly be from me correcting metadata Jellyfin had matched wrongly and removing the bad entries, i.e. ordinary use of the app. Before that, there was also a stale plugins/LDAP Authentication/ folder, last modified in the snapshot on 5 October, which no longer exists on the server (only LDAP Authentication_23.0.0.0 and _24.0.0.0 do).

Oddly, it isn't every deletion. Yesterday I deleted Jellyfin's whole metadata/artists folder (about 42,000 files) and removed the Music library in Jellyfin, which deleted most of metadata/library. Those deletions were correctly reflected in the backup. But these People folders and the LDAP folder were never removed from the snapshot. They get carried into every new backup via the hardlink copy, and since they aren't in the backup's manifest, the integrity checker crashes on them. The backup task itself reports no errors.

This matches what I saw on the old target, where an old plugin folder (plugins/SSO Authentication_4.0.0.4) and thousands of old People and artist images were also left behind. So the migration explained Nextcloud, but this looks like a separate, ongoing bug.

Confirmed: after deleting the stale LDAP folder and the 1,017 stale files from the snapshot, the next Jellyfin backup passed the integrity check for the first time.

So two separate issues:

1. Folders deleted from an app's data are sometimes never removed from the rsync snapshot, so they linger in every backup.
2. The integrity checker crashes on files that aren't in the manifest ("Cannot read properties of undefined (reading 'size')") rather than listing them, which made this much harder to diagnose.

On Cloudron 10.1.5, clicking the stop button on a running integrity check gives:

Unhandled error. Status: 500. unkown: Expected values to be strictly equal: 'number' !== 'string'

with onStopIntegrityCheck() in the trace. The check keeps running. It looks like the task ID is sent as a number where a string is expected.

Workaround: on the server, systemctl stop box-task-<task id> stops it cleanly. The task ID is shown by ps aux | grep taskworker.

Note also: "unkown" in the error message instead of "unknown".

jdaviescoates said:

@timconsidine said:

only copies what has actually been changed

It does. But it still has to check every file to see what has changed and that's what takes the extra time when you've got tens of thousands of files that don't need to be backed up in the first place.

But it turns out file count wasn’t the main problem!

It was mostly two huge database dumps. Fider had an 11 GB logs table (a 15.6 GB dump), left over from older package versions, as described in this thread.

And Matrix had 86 million rows of state for an old room created by @abuse:matrix.org that nobody on my server is even in any more.

Clearing those cut my rsync backup from nearly 3 hours to under 10 minutes!

Moving the Navidrome cache out of /app/data would still be good, but it’s clearly minor by comparison.

@David-0 said:

Weird thing: I've got two instances of Ghost, both configured exactly in the same way (only difference is the domain and that they're using different mailgun/sinch accounts). One works fine, the other does not.

Is the IP of the not working domain whitelisted at the mailgun/ sinch end?

@joseph said:

I guess it's a bit late now since 3.0.0 is already out but thanks for the write up.

Not really, as those logs were still all there even on an instance of Fider that had already updated.

I just cleared 11GB of useless old logs! Thanks @loudlemur !

jdaviescoates said:

...wait perhaps that isn't true and it just hasn't finished indexing everything

I'm really not sure. It certainly looks like it is searching through everything but then the search results it displays are only inbox results (at least in my tests so far).

I think it was perhaps just an indexing thing, as now it is showing me the results I would expect.

I'd still like it to only search the inbox I'm actually in rather than the dozens I've got access to (unless I explicitly ask it to do that).