I have not noticed this issue yet after upgrading to 9.x.

Okay, with 9.0.10, backup was able to be completed.

Do you still want the answers from your first post?

I haven't had a large app backup successfully after 9.0.7. I looked at the logs and saw this message.

/home/yellowtent/box/node_modules/@smithy/smithy-client/dist-cjs/index.js:287
    const response = new exceptionCtor({
                     ^

InvalidArgument: Part number must be an integer between 1 and 10000, inclusive

Would I be able to work around this by increasing the size of upload parts?

Can invidious companion be updated again? I think I'm running into a bug fixed last week.
https://github.com/iv-org/invidious-companion/issues/209

Description

I frequently have the web interface have show apps in old states(like starting or updating). The actual containers are in a different state and once I restart the box service(systemctl restart box), the state shown in the web interface matches again. I've been restarting the service for a few months like this, but figured it would be good to try and hunt down the source of the problem.

Steps to reproduce

Use web interface and see wrong state sometimes.

System Details

Generate Diagnostics Data

Can provide pastebin to support email.

Cloudron Version

v8.3.2

Ubuntu Version

Ubuntu 22.04.5 LTS

Cloudron installation method

• ISO Image?

Output of cloudron-support --troubleshoot

Vendor: GIGABYTE Product: GB-BXi3-5010
Linux: 5.15.0-139-generic
Ubuntu: jammy 22.04
Processor: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz x 4
RAM: 16194568KB
Disk: /dev/mapper/eyecreate--server--vg-root  431G
[OK]    node version is correct
[FAIL]  Server has an IPv6 address but api.cloudron.io is unreachable via IPv6 (ping6 -q -c 1 api.cloudron.io)

On updating to this version, I get "Error: open test.yml: no such file or directory".

Invidious broke again, but now that inv_sig_helper is archived, it seems cloudron should move to this new tool.

Inv-sig-helper should be updated to dcda9f16ae748639cec652ed504809b60f149e71 to fix a youtube change.

@hakunamatata good call! I didn't guess they would only allow a list of proxy sources. Now the proxy works well!

@nebulon this is all I have:

Response Headers

content-length: 16
content-type: text/plain; charset=utf-8
date: Wed, 11 Jun 2025 18
server: nginx
x-firefox-spdy: h2

400: Bad Request

When trying to have an App Proxy set up to proxy my local HomeAssistant to be available on a domain, after logging in to cloudron on the domain it only gives 400 error. Is this a cloudron setup issue or issue with HomeAssistant? I use http for uri and use ipv4 address with port. I'm unable to see anything in proxy app logs.

Looks like another update of SIG helper is needed.

License listed for komga or for the cloudron files?

Edit: there's no license field in manifest, so I just added the license to the repo.

I update my komga repo to the latest version. Been working great with my Kobo.

Wow, there sure are lots of fixes needed for inv sig helper:
https://github.com/iv-org/inv_sig_helper/pull/43

Inv Sig helper could use an update: https://github.com/iv-org/inv_sig_helper/issues/36

Yep, that worked!

I packaged it because I orederd a kobo device and there was good support for it with this software. I packaged Kavita previously, so I'm sure I'll package more in the future when I find good motivation.

I've made a first build of Komga for cloudron:
~~https://git.eyecreate.org/eyecreate/cloudron-komga~~
https://git.cloudron.io/eyecreate/komga
I didn't know if it was worth setting it up with OIDC, but otherwise should be fully usable.
I also included kepubify to help make more compatible with Kobo devices.