Cloudron Forum

fixed for next release https://git.cloudron.io/platform/cloudron-cli/-/commit/09f359f34f23a3acb22067872fd570f23f2db834

Is this happening midway and has there already been some data restored at /home/yellowtent/boxdata/mail/... or is this the first file which fails there?

Also what are the permissions and owner for /home/yellowtent/boxdata/ ?

we should improve on the error message, but what the "repository" here is, is an identifier for the image repo, not a URI as such, so there is no protocol part involved here.

You are on the right track, the app would inspect the host header to know from which domain the request came in from and then handle it accordingly.

On Cloudron you have to set the multiDomain flag in the manifest also https://docs.cloudron.io/packaging/manifest/#multidomain

So I think we get two feature requests from this:

1. provide clamav via the platform, this can be run as a daemon which can then be shared across apps/services to avoid high resource usage
2. investigate what the Cloudron Nextcloud package misses from the Nextcloud AIO bundle, to somehow get the highperformance backend for Nextcloud Talk optionally to work

For the missing indices, I think there is a docs link in your screenshot, can you tell us where that leads to?

ah, so the ACL settings from Cloudron only set the users who can login to surfer. Surfer itself has an admin page to upload and manage files. This is one place where the Cloudron ACLs apply.

However surfer also has its own way of restricting further the public page itself. This is in the surfer settings in the admin UI itself. There you may either set a password or restrict to all users who have access to this app. This is what you probably want to set.

Also note that restart the app is not required for changes in either ACL sets.

I've managed to get clamav somewhat working in the package, however it takes a very long time to startup and uses quite some resources. I doubt we want to include this in the package as such. Since the mail server might also benefit from this, maybe we can integrate this as a platform service like solr into Cloudron and then Nextcloud could use this.

Not clear why Nextcloud marks an optional requirement as red, indicating error. But at the moment the "high performance backend" is not supported as a built-in with the Cloudron package. That requires an additional specialized container as far as I understand and a TURN server (which cloudron has) We may look into this in the future, but it is not on our list currently. But as said it should work as such, just not for meetings with lots of people. You may be able to run that HPB setup on an external server and connect it to your instance, but never tried this https://nextcloud-talk.readthedocs.io/en/latest/quick-install/

The same goes for the recording feature, it is currently not supported out of the box, if you get it working, please share it with us as we are not experts on Nextcloud internals, unfortunately.

Lastly, a similar issue arises from the antivirus addon which depends on clamav installed in ubuntu, which currently is not. The issue with nextcloud plugins is, that they are impossible to support properly through updates as they can do and require "anything". In this case I will see, if we may be able to ship clamav as part of the package. so lets see.

new package is out

Great find indeed. I will prepare a package update to use /ping for healthchecks

Immich update is blocked, since it requires custom code to grant access to the vector extension tables as postgres root user. Have to see how we can workaround that.

@vladimir.d has looked into this these days, he may have more insights. However you can also try to get it to work as a Cloudron OpenID client and if it works let us know, then we can integrate it into the package quickly. So far we hit issues around OAuth grants if I recall correctly.

Do you have any update on this @ruihildt ? We have pending MR which may or may not fix the issue, but we require your input here.

It is on our list, but the OAuth2 integration which we have to use here still has issues. We keep an eye on that though!

It really should be uploaded just like all the other files. You should see something like box:backupformat/rsync Adding fsmetadata.json early on during the backup process.

Maybe we have to debug this on your instance then to see what happens, if you don't see any error in the backup logs itself. For this please enable remote ssh support and send us a mail to support@cloudron.io with Cloudron details.

but you say it is not uploaded to minio then afterwards during a backup?

Actually also with rsync all files should exist for each backup. Can you check the app data to see if that contains the file for a start? It would be at /home/yellowtent/appsdata/<appid>/fsmetadata.json

glad it worked out in the end, still pretty rough. I would recommend to take a fresh backup and clone the app instance from that into a new test instance, just to verify if that works then. Otherwise we have to investigate what the root cause is.

@Benoit for a start check if the backup storage has a fsmetadata.json for the backup which is failing, to make sure the file actually exist on the backup storage side.

Package update is out now. Took a bit to get the tests sorted.