Cloudron Forum

Thank you both @robi and @nebulon

Got it working.

Here are the steps in case if anybody wishes to replicate the process.
It would help a lot to the new Evcc users if the package includes the mentioned changes already.

Steps:

1. Installed Evcc
2. Click: File Manager
3. Click: New > New File
4. Name it this text: evcc.yaml
5. Click: Restart App
6. Refresh the web browser window. A new file will be created named: evcc.db
7. Open the file: evcc.yaml
   There is already a text like this inside:

network:
  schema: http
  port: 7070
  host: evcc.demo.cloudron.io
database:
  type: sqlite
  dsn: /app/data/evcc.db

Click enter 2 times to be able to write to a new line bellow

8. Copy-paste the text from here:
   https://docs.evcc.io/en/docs/installation/configuration#manual

This is the text:

## minimal configuration example

site:
  title: Home # display name for UI
  meters:
    grid: my_grid
    pv:
      - my_pv
    battery:
      - my_battery

# define your loadpoints according your needs
# see https://docs.evcc.io/en/docs/reference/configuration/loadpoints
loadpoints:
  - title: Garage # display name for UI
    charger: my_charger # charger
    vehicle: my_car # default vehicle

# meter definitions
# name can be freely chosen and is used as reference when assigning meters to site and loadpoints
# for documentation see https://docs.evcc.io/docs/devices/meters
meters:
  # replace with your real grid meter
  - name: my_grid
    type: template
    template: demo-meter
    usage: grid
    power: -1000 # 1 kW feed-in
  # replace with your real solar system
  - name: my_pv
    type: template
    template: demo-meter
    usage: pv
    power: 4000 # 4 kW production
  # replace with your real battery
  - name: my_battery
    type: template
    template: demo-battery
    usage: battery
    power: -1000 # 1 kW battery charging
    soc: 50 # 50 % state of charge

# replace with your real charger
# see https://docs.evcc.io/docs/devices/chargers
chargers:
  - name: my_charger
    type: template
    template: demo-charger
    status: C # charging
    power: 2000 # 2 kW charging power
    enabled: true # optional

# replace with your real vehicle (optional)
# see https://docs.evcc.io/docs/devices/vehicles
vehicles:
  - name: my_car
    type: template
    template: offline
    title: blue e-Golf
    capacity: 50 # in kWh

# enter your real grid tariff and feed-in price
# see https://docs.evcc.io/docs/tariffs
tariffs:
  currency: EUR
  grid:
    type: fixed
    price: 0.29 # EUR/kWh
  feedin:
    type: fixed
    price: 0.10 # EUR/kWh

9. Click: Save + Restart App

10. Click on Evcc (URL)

11. There we can see Demo data for: blue e-Golf - charging

Add a new Admin password
Click: Configuration + Add the password again
Click to activate the Experimental features

After this hopefully, the changes can be performed directly inside Evcc via the web browser UI.
If not, the evcc.yaml file will have to be edited manually,
because these terminal commands still aren't working: evcc detect + evcc configure

Hope that was useful

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.

@joseph Thank you very much. That fixed the issue

the post can be marked as solved

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?

Thank you @james

We performed these steps and it was successful:

1. Add these lines in env.sh
   export NODES_EXCLUDE="["ExecuteCommand", "LocalFileTrigger"]"

2. Restarted N8N

3. Performed the test using these steps:

• (+) - Execute command
• Execute Once: ON
• Command: ffmpeg -version
• Test step
• Check the OUTPUT - ok (screenshot attached)

1. We installed Evcc

2. We see this notification:
   Run evcc detect or evcc configure for initial setup. Then restart the app.

3. We went in the EVCC - Terminal and have run both commands and this is the result:

Connecting...
root@448da2a9-736b-4cc3-9370-1e160d939387:/app/code# evcc detect
This account is currently not available.
root@448da2a9-736b-4cc3-9370-1e160d939387:/app/code# evcc configure
This account is currently not available.
root@448da2a9-736b-4cc3-9370-1e160d939387:/app/code#

Since there isn't any post in this category (except for the Package Updates post), has anybody configured Evcc and confirmed it's functionality?

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?

Thank you @robi for the fast response. We tested that and the result is the same

@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?

EspoCRM stopped working.
It's marked as: Not responding

The current version is:
App title & version - Espo CRM 9.2.5
Package version - com.espocrm.cloudronapp@2.19.4

This is the error in the logs:

-----
Nov 21 10:29:15 2025-11-21T09:29:15Z
Nov 21 10:29:15 ==> Could not upgrade
Nov 21 10:29:23 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.12:8000
Nov 21 10:29:33 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.12:8000
Nov 21 10:29:43 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.12:8000
Nov 21 10:29:53 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.12:8000
Nov 21 10:30:03 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.12:8000
Nov 21 10:30:13 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.12:8000
Nov 21 10:30:15 ==> Fixing up modules
Nov 21 10:30:16 ==> Data version is 9.1.9. Expecting 9.2.5
Nov 21 10:30:16 ==> Running upgrade script
Nov 21 10:30:20 => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.12:8000
Nov 21 10:30:20 ==> Failed to upgrade.
Nov 21 10:30:20 ----- Upgrade output -----
Nov 21 10:30:20 Error: Your EspoCRM version (9.1.9) is not supported. Required version: 9.2.4.

Has anybody else had this problem? If yes, please share the solution

@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