Cloudron sends health check notifications for each app ("App xxx is down / back online"). In normal use, this is quite useful, but when working on my Cloudron machine (rebooting it, or whatever), I then get a flood of emails for each application, so my inbox looks like:

Aaa is back up
Bbb is back up
Ccc is back up
Aaa is down
Bbb is down
Ccc is down

Suggested improvements:

• Perhaps it might make sense to delay the activation of health check alerts until (host or app) uptime is over a certain value?
• Consider merging notifications for multiple applications into one (or at least, one mail)

I think you may want to use "healthCheckPath": "/health", rather than /metrics, as that endpoint is actually designed for this use.

Some other confusion: influxd 1.x uses a different configuration format, so I think config.json isn't really useful, as JSON is 2.x and up (I am not certain, I have only used 1.x so far).

Run /app/code/influxd config to get a snapshot of the default configuration.

Once I had that in place, lastly, for whatever reason, I had to pass the config file explicitly as a parameter rather than using the environment variable you were trying: exec "/app/code/influxd" -config /app/data/influxd.conf in start.sh.

Some other configuration recommendations/thoughts:

• I think you should probably also recommend (or somehow, require) authentication, along with creating a default user account, since this is probably going to be run on public-facing servers. For 1.x, see here.
• You should also consider setting reporting-disabled = "true" in the configuration, to prevent phoning home. See the documentation notes here.

Large filenames cause problems, especially with blob-based storage (e.g. S3-compatible services have a key limit of 1024). This gives problems quite easily with hierarchical storage like syncthing where one might have a set of nested folders that quite easily hit that key limit, especially combined with encryption.

Disabling encryption altogether is not desirable in many cases, but it could be worthwhile to allow disabling filename encryption, in some cases.

(As a longer term project, it may also be worth considering ways to circumvent this limit altogether.)

See https://forum.cloudron.io/topic/3050/backup-feedback-minio/ for the initial discussion leading to this request.

https://github.com/damoeb/rss-proxy

Looks like an interesting tool. Also has a docker-based workflow, so might not be too hard to package up

Some feedback, based on having tried out surfer (great little app, by the way!)

• The "App passwords" dropdown for a surfer instance mentions SFTP, which seems a little wrong.
• It might be useful to mention _webdav in the documentation, as an alternative for interacting with surfer?
• It would be great to be able to customize the handling of some mimetypes. For example, when uploading a QML file, surfer will serve it up with application/octet-stream, rather than a text type, which makes browsers offer to download it, which is a bit annoying given how they are basically just text.

Lastly, a small script here for anyone who wants basic "upload this file" functionality but cannot use npm for whatever reason. You are expected to have a file ~/.surfer/auth with two lines (user/pass), and ~/.server/server which contains the bare hostname to upload to. You can use Cloudron's app passwords feature to avoid using your "regular" password, for some added paranoia.

#!/usr/bin/env bash
set -euo pipefail

user=$(head -n1 ~/.surfer/auth)
password=$(tail -n1 ~/.surfer/auth)
server=$(cat ~/.surfer/server)

# the file to upload...
FILE=up.sh.txt
curl -T "$FILE" -u "$user:$password" https://$server/_webdav/
echo "Uploaded to https://$server/$(basename $FILE)"

@doodlemania2 I will try to do so if / when I can get the time to finish poking around, and verify that it actually works once I finish. I just had a child last week, so spare time is a bit hard to come by at present

@nebulon My thinking for write protection was actually that it could - literally - use filesystem permissions rather than introducing a database. Check if the file is writable before deleting/writing, and fail if it isn't writable (or offer to override, which will have to chmod +w it)

I haven't had a chance to look at authentication (or anything else, really) yet unfortunately. Life's been busy.

I did push up what I appear to be running, though, I haven't had a chance to test it independently (I am not using your repo directly, but a rather customised setup, so I copied my changes into it by hand).

You can see my fork here: https://github.com/rburchell/cloudron-influxdb

Sometimes, there are notifications, like this one:

Failed to new certs of xxx: Unexpected status: invalid. Renewal will be retried in 12 hours

These often require extra context to understand what went wrong, or how to rectify the problem (for many backup failures, for example).

It would be great if the notification provided some sort of a pointer to jump into Cloudron's logs at the time of the event in this case, to dig into the problem further.

Hi,

I noticed that beam.smp is using a lot of CPU inside my cloudron instance. I tracked this down to belonging to onlyoffice, and doing some further digging, I found this post that might be interesting.

tl;dr:

When I set the number of scheduler threads to 1 the CPU usage dropped from 23 % to 3 %.

Setting RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS="+S 1:1" apparently does the trick, and there's a linked issue on the onlyoffice github that appears to do exactly that as a part of their Dockerfile.

I'm unsure how to test this, but perhaps this may be the same issue / fix for Cloudron's case, too?

@girish Yes, that would have been the case. Sorry for not responding here, real life has been busy the past few days

Thanks for the fix!

After upgrading to 6.3, I have a single app (Gitea) that seems to be sending upgrade notifications constantly - apparently 4 times a day or so. Not sure what the root problem is there - please let me know if I can be of any help.

@girish Fix seems to have worked for me, thanks!

For satisfying my own curiosity, can you explain why using the mountpoint method was no longer sufficient?

@girish Yeah, I'm using uid=yellowtent,gid=yellowtent, so I think that is indeed my problem

@nebulon said in Backups appear to not work after upgrade:

@robin Is that mountpoint by any chance sshfs?

Yes, it is indeed sshfs

As the title says...

Provider mountpoint
Location /mnt/ibt/backup
Storage Format rsync
Encryption is enabled if that matters.

I'm getting this as a notification:

Unable to chown:EACCES: permission denied, chown '/mnt/ibt/backup/snapshot/app_22f1c4f7-7480-405d-aae9-258e7cc5cee7/O4m2+us4iuqCWWOtbom2RZncffaPgi9HNTF936n7CaU'

However: I think the error is incorrect, or weird, or something, though, because the permissions are most definitely correct. Cloudron is the only thing that ever touches that mountpoint, and it has access to do whatever it wants:

-rw-r--r-- 1 yellowtent yellowtent 3732 Jul 9 15:41 /mnt/ibt/backup/snapshot/app_22f1c4f7-7480-405d-aae9-258e7cc5cee7/O4m2+us4iuqCWWOtbom2RZncffaPgi9HNTF936n7CaU

I tried removing the problematic file, and forcing a new backup, but the same error happened again.

@girish Yeah, I ran:

/home/git/gitea/gitea convert -c /run/gitea/app.ini as user git, and now things seem converted:

ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci ROW_FORMAT=DYNAMIC

On the downside, the convert tool seems to unconditionally convert, and is quite slow, so I guess it can't easily be run as part of the startup process or something

Searching around their issues, I find this: https://github.com/go-gitea/gitea/issues/11081

My existing install has this:

ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC |

So perhaps this might have been a bug that they corrected in a release sometime after I had already installed?

Long story short, I've got some problems with encoding.

See the following Github issue: https://github.com/go-gitea/gitea/issues/16016
Which links to the following solution: Are you using MySQL? If so you probably need to convert the tables to utf8mb4, gitea convert can help with that but take a backup before doing it.

I don't remember enough about MySQL anymore to know how to look into this myself, but I'm happy to try help test if you want to try hold my hand, @girish