Cloudron Forum

Hi @girish,

Thank you for the support! Your solution worked perfectly, and now the domain is successfully added to Cloudron.

I'll be waiting for the patch release. Should I revert the manual change in the /home/yellowtent/box/src/dns/cloudflare.js file before updating Cloudron with the patch, or will it be handled automatically during the update?

Thanks again for your help!

We followed the official Cloudron tutorial for moving data to an external volume:
https://docs.cloudron.io/storage/

During the migration process, we faced several issues:

Issue #1: Docker Restart Loop

We attempted to migrate /home/yellowtent/platformdata/logs, but the migration failed because Docker was still using this directory even after stopping the Docker service. Docker automatically restarted itself, preventing the move. To resolve this, we ran the following command:

systemctl mask docker

This allowed us to stop Docker and proceed with the migration.

We attached an ext4 volume from Hetzner to the server, and there is sufficient space on the volume for Cloudron data.

Issue #2: Services Fail to Start After Migration

After completing the migration we restarted services:
box, docker (unmask docker), nginx, collectd

But most services failed to start in "Services" tab in Cloudron. For example graphite, postgresql, unbound, etc. And we can't restart them due to error.

The error message from Cloudron (when we want to start service) is as follows:

(HTTP code 500) server error - Cannot restart container mysql: failed to create task for container: failed to initialize logging driver: dial unix /home/yellowtent/platformdata/logs/syslog.sock: connect: connection refused

Troubleshooting Steps

1. We verified that /mnt/tc-cloudron-volume-1/platformdata/logs/syslog.sock is being created with the root:root ownership and permissions:

srw-rw-rw- 1 root root 0 ...

2. We updated /etc/rsyslog.conf to include the following lines:

module( load="imuxsock" SysSock.Name="/mnt/tc-cloudron-volume-1/platformdata/logs/syslog.sock" SysSock.Owner="yellowtent" SysSock.Group="yellowtent" SysSock.Perm="0666" )

Despite restarting rsyslog and Docker multiple times, the issue persists.

3. We also manually removed the syslog.sock file, restarted rsyslog, and confirmed that it recreates the file. However, it still reverts to root:root ownership.

Current State

• The syslog.sock file is being created with root:root ownership, which prevents Docker containers (e.g., MySQL, PostgreSQL) from initializing correctly.
• Even after applying the correct ownership and permissions manually (chown yellowtent:yellowtent and chmod 0666), the services fail to start.
• We suspect this might be due to a deeper integration issue between rsyslog, Docker, and Cloudron's specific logging requirements.

Environment Details

• Cloudron version: v8.2.3
• OS: Ubuntu 22.04.1 LTS
• Rsyslog version: 8.2.3
• Hosting provider: Hetzner
• Attached volume: ext4 formatted with sufficient space

Request for Assistance

We kindly request guidance on how to resolve the syslog.sock ownership issue and ensure proper integration of logging between Docker and Cloudron after migration to an external volume.

Thank you in advance for your help!

Hi @joseph,

No, I haven’t tried running
systemctl restart cloudron-syslog

Do you think this could help resolve the issue?

I followed the official Cloudron documentation for migrating the default data directory: https://docs.cloudron.io/storage/. However, the documentation doesn’t mention restarting cloudron-syslog as part of the process.

To try this command, I’ll need to wait until my scheduled maintenance window at night to work on the server. If you have any other suggestions, please let me know so I can try everything during my maintenance period.

Thank you for your assistance!

@joseph , got it!
thanks. will do and let you know about result

Hi @joseph ,

Yes, your new instructions at https://docs.cloudron.io/storage/ were very helpful! However, I still had to manually restart the services on the /services page in the Cloudron admin panel.

Regarding the time it takes to reindex disk information, it happened within the same day for me. I’ll continue monitoring the system's stability over the next few days to ensure everything is running smoothly.

Thank you so much for your help! Thanks to your assistance, I was finally able to resolve the issue with running out of disk space

@joseph , may be something wrong with my Cloudlfare account. Can you give me all API requests that Cloudron did when setup new domain with Cloudflare?
I will check it manually.

Hi Joseph,

I'm experiencing an issue where I can't start the database, and it's urgent as users are contacting me on multiple channels. I've been troubleshooting for about 30 minutes, and a restart didn't help. I attempted to restore the server, but now I'm facing additional issues. My Default Data Directory was migrated according to the Cloudron documentation (https://docs.cloudron.io/storage/#default-data-directory), and as a result, I'm unable to start some of the Cloudron services.

Could you please help me resolve these issues?

Thank you for your assistance.

All applications are down. I need to fully restore the server((
Auto-update will be permanently disabled. I don’t understand why I enabled it—I always disable it, and it only updates after several weeks.

@joseph, @girish — let me help clarify some real-world use cases your clients face:

We use NocoDB, Directus, n8n, and similar tools with large datasets.
Cloudron is an excellent hosting platform and fully capable of being used in production environments.

However, it’s concerning to see how the update logic currently works — for example, during a version upgrade, the script upgrades the database and freezes all other apps.
Imagine a client running NocoDB with 500 GB of data — even if it's the only app, this can be a serious issue.

You've added powerful applications to the Cloudron App Store that are clearly meant for serious, data-heavy production use. But this makes it even more critical to improve update and recovery mechanisms.

Please consider implementing the following improvements:

• Add the ability to force-stop an update and roll back to the previous stable state.
• Ensure that other apps are not frozen during an upgrade, especially if they are not directly affected.

I’m even willing to pay for such improvements as an optional feature or extension.

I’ve already invested a lot of time trying to resolve these issues, and I’m still stuck — any help or solution would be highly appreciated.

Hello @girish , @joseph

After a second attempt to upgrade to version 8.3.1, I'm still encountering serious issues.

I’ve already spent a significant amount of time creating a new server and restoring from backups. Once again, during the upgrade to 8.3.1, all apps with PostgreSQL are stuck in the state:

Restarting - Waiting for platform to initialize

Checking the box logs, I see repeated PostgreSQL backup and export operations, for example:

2025-03-24T20:10:48.541Z box:services Backing up postgresql  
2025-03-24T20:10:49.129Z box:services pipeRequestToFile: connected with status code 200  
2025-03-24T20:10:49.152Z box:services exportDatabase: Exporting addon postgresql of app 36863357-62c8-4750-9f7e-a20040bc1d15  
...  
2025-03-24T20:11:34.186Z box:services exportDatabase: Exporting addon postgresql of app 42f73f7a-f67b-4690-871a-f422c56bf4fd  

I'm unsure if I should just wait — and if so, how long?
Why is there no way to stop this process or manually recover my apps?

From a user experience perspective, this feels unfriendly and very frustrating.

Has anyone successfully upgraded to 8.3.1?
At this point, I’ve already spent over a week trying to make it work.