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:
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.
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
/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 ...
/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.
syslog.sock file, restarted rsyslog, and confirmed that it recreates the file. However, it still reverts to root:root ownership.syslog.sock file is being created with root:root ownership, which prevents Docker containers (e.g., MySQL, PostgreSQL) from initializing correctly.chown yellowtent:yellowtent and chmod 0666), the services fail to start.rsyslog, Docker, and Cloudron's specific logging requirements.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:
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.
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.
Hi,
I'm having issues restoring NocoDB v1.32.0 from a backup. The restore task consistently fails.
Environment:
Problem:
After running the restore from backup, the task fails. I restarted PostgreSQL and tried "Retry task", but it still fails.
PostgreSQL logs:
add: adding database db4fd86909c95a4f079147e3854b98203f
2026-01-28 08:55:34.684 UTC [974] root@postgres ERROR: role "db4fd86909c95a4f079147e3854b98203f" already exists
2026-01-28 08:55:34.684 UTC [974] root@postgres STATEMENT: CREATE ROLE db4fd86909c95a4f079147e3854b98203f NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOLOGIN
add: failed to create database. error: role "db4fd86909c95a4f079147e3854b98203f" already exists
Task error:
Addons Error: Error setting up postgresql. Status code: 500 message: role "db4fd86909c95a4f079147e3854b98203f" already exists
It seems the restore process tries to create a PostgreSQL role that already exists from a previous failed attempt. Is there a way to clean up this orphaned role, or should Cloudron's restore process handle this case with CREATE ROLE IF NOT EXISTS or DROP ROLE IF EXISTS before creating?
Any help would be appreciated. Thank you!
Thank you @james and @joseph for your quick responses!
1) Backup provider: AWS S3
2) Tried Joseph's suggestion - install new NocoDB and import backup config:
I created a fresh NocoDB app and tried to import the backup configuration from AWS. Got a different error - seems like the backup archive might be corrupted:
BoxError: tarExtract pipeline error: incorrect header check
at tarExtract (/home/yellowtent/box/src/backupformat/tgz.js:225:26)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async /home/yellowtent/box/src/backupformat/tgz.js:248:9
at async promiseRetry (/home/yellowtent/box/src/promise-retry.js:17:20)
at async Object.download (/home/yellowtent/box/src/backupformat/tgz.js:244:5)
3) Tried importing into the existing app:
Same PostgreSQL role error as before:
Addons Error: Error setting up postgresql. Status code: 500 message: role "db4fd86909c95a4f079147e3854b98203f" already exists
Summary of the situation:
tarExtract pipeline error: incorrect header check (possibly corrupted backup?)role already exists errorIs there a way to:
db4fd86909c95a4f079147e3854b98203f so the existing app restore can proceed?Let me know if you need any additional logs or information.
Hi @joseph . Thanks!
Yes, the issue was with the encryption password. I successfully created a new app from the backup.
However, one question remains: how can I restore a backup to NocoDB without recreating the app?
The original restore (to the existing app) kept failing with the role already exists PostgreSQL error. Could this be related to memory limits? I checked and there seemed to be enough memory available everywhere.
For context: my NocoDB has many records plus connections to external databases.