Cloudron Forum

This was handled via support. The root cause was a bug in our addon handling. Fix is https://git.cloudron.io/cloudron/box/-/commit/01945675edfd705d1a19d6ed9e40633b721be8f7

@Jarod In the AWS Marketplace Image (AMI) , route53 is disabled in the setup screen. It is apparently against Marketplace policy to take route53 API credentials (a member of their team had reached out to us and notified us about this). So, if you use the AMI, then the setup screen will not show route53 as an option anymore.

Hi, we did not initiate an update manually. According to the logs, Cloudron updated to v8.0.3 this morning at 6:58. The message "removing containers for upgrade" was still there at midday. Error message when going to an app: "This app is currently not responding. Please try refreshing the page in a few minutes." After a manual reboot, all apps were "Configuring (Queued)" for a while. Now the first apps are running again. Yeah

@girish I had the same problem with 2 apps (one recently automatically upgraded[n8n] and another installed now [archivebox] and both reported "Starting" in the dashboard despite working URLs (status really = "Running'). systemctl restart box cleared up the dashboard. But in checking box.log, I can see where about 2 days ago, box:apphealthmonitor app health {running, stopped, unresponsive} stopped running. I did not see an error, just nothing in the log. After systemctl restart box, the entry began appearing in box.log. The only unusual aspect of my Cloudron is that I have been experimenting with a privately hosted app. FYI, that app was "Running". Hope this is helpful in figuring out what is going on.

Thanks, it's solved. No disk wasn't changed. It's running on AWS.

There are some further notes in https://docs.directus.io/getting-started/architecture.html#versioning . For them, "Minor — A new feature or meaningful improvement to an existing feature: may or may not be breaking." I think Cloudron packaging has to follow what upstream does, otherwise, every minor release now becomes a major in Cloudron. Maybe best to turn off automatic updates for Directus and analyze each Cloudron package update?

probably via https://forum.cloudron.io/post/71420

@Kubernetes thanks for reporting!

@jdaviescoates Hello I don't know if this is much help, but I have landed on using the following procedure: First, on my Cloudron box, I mount my library as a shared volume. I then sync this volume to the Calibre web app using the following syntax: rsync -azP --delete /mnt/volumes/<volumeid>/ /home/yellowtent/appsdata/<appid>/data/library Notice the trailing slash on the source, but not on destination. The drawback on this method is that changes I make in the Calibre web app are overwritten when doing an rsync. So I try to not use the web app for changes (uploads, metadata edits etc). More on this on this topic: Calibre not able to write on mounted (cifs) volume

Thank you, that has solved the problem!

... or even in the docs (which are, by the way, excellent!)

The full solution is : First run (as-is): mysql -uroot -ppassword box -e "delete from blobs where id='sftp_private_key' OR id='sftp_public_key'" Then, /home/yellowtent/box/setup/start.sh to complete the migrations Then, systemctl restart box

@girish worked on the 20.x instance

Worked on v 7.3 same issue.

Check the contents of/home/yellowtent/box/VERSION . Is it 7.4.3 ? If so, you can run the commands below and make it work again . After you get it back, snapshot the server and upgrade ubuntu when possible. mkdir -p /usr/local/node-16.18.1 curl -sL https://nodejs.org/dist/v16.18.1/node-v16.18.1-linux-x64.tar.gz -o /tmp/node.tar.gz tar zxvf /tmp/node.tar.gz --strip-components=1 -C /usr/local/node-16.18.1 rm /tmp/node.tar.gz ln -sf /usr/local/node-16.18.1/bin/node /usr/bin/node ln -sf /usr/local/node-16.18.1/bin/npm /usr/bin/npm systemctl restart box

This continues in https://forum.cloudron.io/topic/9514/panic-mode-update-failed

We can't change the doc page yet atleast until 7.5 is stable. Also, 18.04 is still supported to install pre-7.4 releases.