Cloudron Forum

Thank you very much
@robi @joseph @crazybrad and @p44

The settings are correct because we are also using Backblaze for the backups.

We tried all your recommendations and nothing worked.

Has ANYBODY successfully performed the Typebot-BackblazeB2 connection?

If yes, please share the settings. We will perform the tests on our side also. Then we will send the detailed steps for the Cloudron developers to add in the Typebot documentation (if they wish) for everybody to benefit

The latest version of Cloudron 7.7.2
made all newly installed Uptime Kuma's to be unavailable to be loaded upon installation.

I even tried to install older versions of Uptime Kuma. Again the same result.

Then I did the installation on Cloudron 7.7.1 and it works.

If possible please fix this bug before pushing 7.7.2 in the Stable Updates section.
Thanks

Thank you @james

We have performed the steps and it's working

Here are the steps in detail (for noobs like me to replicate it):

1. Log in Cloudron + select EspoCRM + Click on the Repair tab: Enable Recovery Mode
2. Click: Terminal
3. Copy paste this:
   nano +704 application/Espo/Core/Utils/File/Manager.php
4. This is the original line:
   if (is_dir($dirPath) && is_writable($dirPath)) {
5. Change it to this:
   if (is_dir($dirPath) && is_writable($dirPath) && is_link($dirPath) === false) {
6. On the keyboard click: CTRL + X
   Then click to confirm: Y
7. Copy paste this:
   mkdir -p /run/espocrm/cache
   mkdir -p /run/espocrm/logs
   php command.php extension -u --name="Advanced Pack"
8. Close the Terminal window
9. Click to Disable the Recovery mode
   there is no need to Restart EspoCRM
10. Log in EspoCRM as admin >>> extensions

• 1 more step to update the Extension:
  Since the old Extension version was uninstalled, now we upload the new version + click Install

@james We noticed that the change in the Manager.php file is not permanent.
So this means that we would have to go through all these steps each time an Extension update is required.

Business-wise, this will reduce the client-retention rate of the Cloudron userbase. Especially those that aren't tech experienced.

Ideally the extension updates would be performed by the EspoCRM admin just uploading the new version inside EspoCRM (UI) and it replaces the old version.
Is it possible for the Cloudron team some day to push an update to the EspoCRM package that applies this change permanently?

@girish Thank you very much.

We run the tests again by reinstalling it again.
It seems that the problem originated when we installed multiple Apps and then UptimeKuma somehow broke. So we installed them one by one, and now it's ok.

Hi

When we try to edit the config files using the File Manager for any app this happens:
(Example with Matrix)

1. Edit file: homeserver.yaml (owner: cloudron)
2. Click: Save + Close
3. In the folder there is a new file: homeserver.yaml.1 (owner: root)
4. Click: Restart App
5. The new file has changed owner: homeserver.yaml.1 (owner: cloudron)
6. And there aren't any changes performed inside: homeserver.yaml (owner: cloudron)
7. The changes aren't applied in the app

Is it possibly something that we are doing wrong, or is it just a temporary bug?

With the recent changes to MinIO, we are forced to use another solution for the Typebot storage.

So we took a look at BackblazeB2.
Backblaze is very cost-effective 1TB=$6/m so it's a good solution.

We tried the following configuration:

1. Inside Backblaze
   Activated the Bucket
   Set CORS as receive from all
   Left the Lifecycle rules the same
   In the settings tested both Private + Public

2. In the Typebot backend file added the standard: (for this specific bucket)

export S3_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
export S3_SECRET_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
export S3_BUCKET=typebotstorage
export S3_ENDPOINT=s3.us-east-005.backblazeb2.com
export S3_SSL=true
export S3_REGION=us-east-005
+
It didn't work.

Made tests with:
export STORAGE_TYPE=s3
export S3_REGION=US
export S3_REGION=us
export S3_PORT=443
+
Also, no results.

And yes, we performed an App restart per each individual change.

Does anyone have an idea how to make it work?

@james Thank you for the fast response
Cloudron version: v8.3.2 (Ubuntu 24.04.3 LTS) (I have included the OS for just in case)
EspoCRM version: Espo CRM 9.2.2
Package Version: com.espocrm.cloudronapp@2.19.1
Advanced Pack - Extension version: advanced-pack-3.11.7

There is a bug with the latest Cloudron update.

Before this update, on the Cloudron login page it was: Login to BRANDNAME
Now it is: Login to Cloudron

Can we get a timeline on when this will get fixed?

Since only the person that has paid for it is able to get updates, I'll send the file to you in the private chat (for testing purposes)

Hello everybody

The last 2 Cloudron installations on Azure VPS and Contabo VPS, have resulted in the same problem.
The Let's Encrypt Certificate failed to be issued.

Here is the Contabo VPS log:

Oct 27 21:43:28box:taskworker Starting task 3. Logs are at /home/yellowtent/platformdata/logs/tasks/3.log
Oct 27 21:43:28box:tasks update 3: {"percent":101,"message":"Ensuring certs of my.chat.newtonhealthcore.com"}
Oct 27 21:43:28box:reverseproxy ensureCertificate: my.chat.newtonhealthcore.com needs acme cert
Oct 27 21:43:28box:cert/acme2 getCertificate: for fqdn my.chat.newtonhealthcore.com and domain chat.newtonhealthcore.com
Oct 27 21:43:28box:cert/acme2 Acme2: will get cert for fqdn: my.chat.newtonhealthcore.com cn: my.chat.newtonhealthcore.com certName: my.chat.newtonhealthcore.com wildcard: false http: true
Oct 27 21:43:28box:cert/acme2 getCertificate: start acme flow for my.chat.newtonhealthcore.com from https://acme-v02.api.letsencrypt.org/directory
Oct 27 21:43:31box:cert/acme2 Attempt 1 failed. Will retry: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:43:51box:cert/acme2 Attempt 2 failed. Will retry: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:44:11box:cert/acme2 Attempt 1 failed. Will retry: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:44:11box:cert/acme2 Acme2: will get cert for fqdn: my.chat.newtonhealthcore.com cn: my.chat.newtonhealthcore.com certName: my.chat.newtonhealthcore.com wildcard: false http: true
Oct 27 21:44:11box:cert/acme2 getCertificate: for fqdn my.chat.newtonhealthcore.com and domain chat.newtonhealthcore.com
Oct 27 21:44:11box:cert/acme2 getCertificate: start acme flow for my.chat.newtonhealthcore.com from https://acme-v02.api.letsencrypt.org/directory
Oct 27 21:44:11box:cert/acme2 Attempt 1 failed. Will retry: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:44:31box:cert/acme2 Attempt 2 failed. Will retry: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:44:51box:cert/acme2 Attempt 2 failed. Will retry: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:44:51box:cert/acme2 Acme2: will get cert for fqdn: my.chat.newtonhealthcore.com cn: my.chat.newtonhealthcore.com certName: my.chat.newtonhealthcore.com wildcard: false http: true
Oct 27 21:44:51box:cert/acme2 getCertificate: for fqdn my.chat.newtonhealthcore.com and domain chat.newtonhealthcore.com
Oct 27 21:44:51box:cert/acme2 getCertificate: start acme flow for my.chat.newtonhealthcore.com from https://acme-v02.api.letsencrypt.org/directory
Oct 27 21:44:51box:cert/acme2 Attempt 1 failed. Will retry: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:45:11box:cert/acme2 Attempt 2 failed. Will retry: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:45:31box:reverseproxy ensureCertificate: error: connect ENETUNREACH 2606:4700:60:0:f53d:5624:85c7:3a2c:443
Oct 27 21:45:31box:tasks update 3: {"message":"Rebuilding app configs"}
Oct 27 21:45:31box:reverseproxy writeDashboardConfig: writing admin config for chat.newtonhealthcore.com
Oct 27 21:45:31box:reverseproxy writeCertificate: my.chat.newtonhealthcore.com will use fallback certs because acme is missing
Oct 27 21:45:31box:shell reload spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx
Oct 27 21:45:31box:mailserver checkCertificate: certificate has not changed
Oct 27 21:45:31box:shell notifyCertChange spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh box
Oct 27 21:45:31box:tasks update 3: {"message":"Checking expired certs for removal"}
Oct 27 21:45:31box:reverseproxy cleanupCerts: done
Oct 27 21:45:31box:tasks setCompleted - 3: {"result":null,"error":null}
Oct 27 21:45:31box:tasks update 3: {"percent":100,"result":null,"error":null}
Oct 27 21:45:31box:taskworker Task took 122.95 seconds

Have any of you found a solution for this?

@girish Thank you. Your solution did the trick.
But we needed the ipv6 to be functional.
So what we did to make it work was > reinstall Ubuntu 22.04 LTS OS and didn't install unbound in advance. All is good now.

Thank you @nebulon
Please release the next patch when possible, because this means that we can't do any config editions to any of the Apps

Thank you @nebulon and @joseph

Hi

Have tried 10+ times to run a Nextcloud migration.

But we are constantly getting the same error.

We hope that this can be solved. Since this forum is public, the solution will be available for everyone else who will have the same problem

Task Error in the Nextcloud > Repair Tab:

Addons Error: Unexpected response code or HTTP error when piping /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e: status 500 complete false

Logs:

17 06:41:29 box:tasks update 2805: {"percent":65,"message":"Download finished 2024-07-15-190000-564/app_vtmg.link_v4.22.2/postgresqldump to /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump"}
Jul 17 06:41:29 box:backupformat/rsync Recreating empty directories in {"localRoot":"/home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e","layout":[]}

Jul 17 06:44:37 box:backuptask downloadApp: time: 27101.091

Jul 17 06:44:37 box:tasks update 2805: {"percent":70,"message":"Restoring addons"}

Jul 17 06:44:37 box:services restoreAddons

Jul 17 06:44:37 box:services restoreAddons: restoring ["postgresql","sendmail","ldap","redis","localstorage","scheduler","turn"]

Jul 17 06:44:37 box:services Restore postgresql

Jul 17 06:44:37 box:services pipeFileToRequest: piping /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e

Jul 17 06:48:43 box:services pipeFileToRequest: piped /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e

Jul 17 06:51:44 box:services pipeFileToRequest: request completed with status code 500

Jul 17 06:51:44 box:apptask run: app error for state pending_restore: BoxError: Unexpected response code or HTTP error when piping /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e: status 500 complete false at ClientRequest.<anonymous> (/home/yellowtent/box/src/services.js:1311:60) at ClientRequest.emit (node:events:518:28) at ClientRequest.emit (node:domain:488:12) at HTTPParser.parserOnIncomingClient (node:_http_client:698:27) at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17) at Socket.socketOnData (node:_http_client:540:22) at Socket.emit (node:events:518:28) at Socket.emit (node:domain:488:12) at addChunk (node:internal/streams/readable:559:12) at readableAddChunkPushByteMode (node:internal/streams/readable:510:3) { reason: 'Addons Error', details: {} }

Jul 17 06:51:44 box:taskworker Task took 27570.192 seconds

Jul 17 06:51:44 box:tasks setCompleted - 2805: {"result":null,"error":{"stack":"BoxError: Unexpected response code or HTTP error when piping /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e: status 500 complete false\n at ClientRequest.<anonymous> (/home/yellowtent/box/src/services.js:1311:60)\n at ClientRequest.emit (node:events:518:28)\n at ClientRequest.emit (node:domain:488:12)\n at HTTPParser.parserOnIncomingClient (node:_http_client:698:27)\n at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17)\n at Socket.socketOnData (node:_http_client:540:22)\n at Socket.emit (node:events:518:28)\n at Socket.emit (node:domain:488:12)\n at addChunk (node:internal/streams/readable:559:12)\n at readableAddChunkPushByteMode (node:internal/streams/readable:510:3)","name":"BoxError","reason":"Addons Error","details":{},"message":"Unexpected response code or HTTP error when piping /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e: status 500 complete false"}}

Jul 17 06:51:44 box:tasks update 2805: {"percent":100,"result":null,"error":{"stack":"BoxError: Unexpected response code or HTTP error when piping /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e: status 500 complete false\n at ClientRequest.<anonymous> (/home/yellowtent/box/src/services.js:1311:60)\n at ClientRequest.emit (node:events:518:28)\n at ClientRequest.emit (node:domain:488:12)\n at HTTPParser.parserOnIncomingClient (node:_http_client:698:27)\n at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17)\n at Socket.socketOnData (node:_http_client:540:22)\n at Socket.emit (node:events:518:28)\n at Socket.emit (node:domain:488:12)\n at addChunk (node:internal/streams/readable:559:12)\n at readableAddChunkPushByteMode (node:internal/streams/readable:510:3)","name":"BoxError","reason":"Addons Error","details":{},"message":"Unexpected response code or HTTP error when piping /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e: status 500 complete false"}}
[no timestamp]  Unexpected response code or HTTP error when piping /home/yellowtent/appsdata/57af8641-8ca3-4a61-b18a-cbf6308fb45e/postgresqldump to http://172.18.30.2:3000/databases/db57af86418ca34a61b18acbf6308fb45e/restore?access_token=072212caff8830b05a63b50516fa15953eeb2cd970e6668dbf7268d8dd43d609dcb58e6bf039e0b3befdd38b137de76828624185d3b0d6340a38f4e7aa467a2842bd64880a0392f4644e69faf49c4049fedcb4a2b3b41f7934a82d91e2453ea7172dad77131adb9389793dad635596d1c8db452a816a70985ed2941bfdc5d78e&username=user57af86418ca34a61b18acbf6308fb45e: status 500 complete false

Additional info if needed:

1. The migration is run from a Linode VPS (Nexcloud on Cloudron) Ubuntu 22.04 LTS OS
   to a Dedicated server Ubuntu 24.04 LTS OS
2. In order so that there isn't any PostgreSQL database corruption, before the Backup was created we put Nextcloud in Recovery mode (so that the database isn't edited). We also tested without putting it in Recovery mode and the result was the same.
3. The migration is running from a Linode Object Storage

Thank you @nebulon and @girish very much!

Yes @nebulon it's a quite big database. This Nextcloud has around 6000 users.
The disk has above 1TB SSD so that was ok.

Thank you @girish for the detailed steps. They were very helpful!
The import was a success.

Note: The change isn't persistent on a Reboot.
It would be nice to change this:
max_connections = 500
to this:
max_connections = 3000
If the server is powerful enough, it should be able to sustain the x6 boost.
The only challenge is how to make the change persistent after Reboot

Thank you @girish that will be very useful

I wish that we could do that, but this specific client doesn't want the configuration to be done. He is afraid that something might break. We assured him that all will be ok, but he insists. We must respect his wishes.

Perhaps in the near future we will try it for some other client with high number of users.