Cloudron Forum

I think there may be an issue in the mapping between the Synology LDAP and Cloudron LDAP If you look at the first screenshot provided by imc67, we have the option to select which LDAP profile to use. If you use the standard profile, you immediately run into the issues that imc67 described. However if you change the profile to custom (see screenshot below), everything checks out fine except for the "Check server schema" which goes away if one enables CIFS plain text authentication. But then you still get stuck when the Synology tries to join the Cloudron directory. [image: 1744372954639-4e73954b-31d8-4432-a657-ccab1fd989ca-image-resized.png] [image: 1744373380929-e85d7121-05fd-4a61-9082-c2ff648d3252-image-resized.png] [image: 1744373443601-809c7691-aae3-4fc0-bfe8-cec2cc30507f-image-resized.png] I'm trying to find the logs on the synology to get more details. Here are the synology docs for how to join a Synology NAS to an external LDAP directory: https://kb.synology.com/en-me/DSM/help/DSM/AdminCenter/file_directory_service_join?version=7

@SansGuidon said in Some struggles with Cloudron migration: pebkac What? Googling . . . PEBKAC stands for "Problem Exists Between Keyboard and Chair". It's a tech support term, often used humorously or dismissively, to indicate that a problem is caused by user error rather than a technical issue. In essence, it's attributing the problem to the user's actions or lack of understanding, rather than a software or hardware malfunction. AHHHHH! I know the German version "Das Problem sitzt vor dem Bildschirm" litteral translation "The problem is sitting in front of the screen". Nice one @SansGuidon said in Some struggles with Cloudron migration: it makes actually sense to refresh the guide reader about the network requirements Good point! Just a "remember your Network setup!" with a link to the other doc would be enough. Right? @SansGuidon said in Some struggles with Cloudron migration: Also maybe not everyone is willing to rely solely on Cloudron config for the security. Hetzner gives lot more power to users and control, and Cloudron sometimes feels a bit too vague. Let me be brutally honest with you. German mode enabled. 99% of users that use Cloudron do not have the knowledge and experience to proivde that. What Cloudron provides is enough for the 99%. Generally speaking, not targeted towards you. IMO everything further is "expert mode" and the expert should know what to do. And if the expert does not know how, he should either learn or pay. @SansGuidon said in Some struggles with Cloudron migration: As a power user (DevOps) and busy dad, Cloudron feels both nice or confusing/limited at times depending what I want to do I get that That is the gilded cage experience and to some extent necessary to keep support low. If you are working in DevOps, I've built multiple customer solutions with Cloudron, Cloudron Gitlab, Cloudron DockerRegistry and the Gitlabrunner to fully automate, development, staging and production deployments. It is possible, but you need a firm grasb on what Cloudron does and how it does things. Then you can make it do some crazy things. @SansGuidon said in Some struggles with Cloudron migration: The mounts issues errors were for most related to network. The message must be clearer. Error message improvment. Everyone can benifit from that. Should there be a normal message with a button "more details" for power users like you and me? @SansGuidon said in Some struggles with Cloudron migration: I could use Hetzner for DNS but we have already a long term subscription with Hostinger for several domains so we are anyway still stuck a bit. Also I could argue that putting all my eggs on same provider is risky. I had an outage with Contabo in the past where both VPS and Backups location were impacted. this kind of situation is a pain in the ass. Egg Basket, agreed. If not Hetzner, some other supported DNS provider that fits your needs so you get rid of the manuall labor? => https://docs.cloudron.io/domains/ My top picks in no order are: https://desec.io/ Cloudflare Hetzner DigitalOcean @SansGuidon said in Some struggles with Cloudron migration: And I wanted to contribute this thread in the hope to open a debate about this and improve the overall experience. Yes please! Always and more of that. What ever you find that is "meh", report it in the forum. Everyone benefits.

I just had the issue while attempting to migrate to a new Cloudron restore, at the step of restoring a full backup and this despite following exactly the steps in Cloudron guide for restoring backups. I quickly solved it through: Reviewing unbound service status shows everything looked ok I had a doubt about the private key password being good, as the backup configuration didn't clarify that in the UI. I just put my private key password again, and attempted the restore button, this time it works. So it's good to mention maybe in the guide that the private key password should be double checked even if using a preexisting backup configuration generated from the previous Cloudron instance.

Using tgz instead of rsync did let the backup run normally, at least once right now. Let's call this a workaround for now, I'll see if this works regularly.

@potemkin_ai & @kk_cloudron On my side I was also having the issue "queryNs ETIMEOUT" , and it was because my outbound UDP port 53 was not open. I just had to add it like that on my Hetzner Cloud Firewall : [image: 1744283926608-7bf48621-4935-4413-af8d-775b9a05abe2-image-resized.png]

I use netcup too, I disabled IPv6 on the server entirely and since everything has been working with no issues. Though disabling IPv6 persistently on reboot was not straightforward and had to be done modifying netplan config, see above on the thread (https://forum.cloudron.io/post/102554).

@joseph Okay, it's solved. It works a bit differently than with Infomaniak, since Infomaniak doesn't allow you to modify outbound firewall rules yourself — for example, you have to open a support ticket to request outbound access to port 25. With Hetzner, I just had to get used to their setup: I needed to manually open the outbound port on the Hetzner Cloud firewall side. : https://docs.cloudron.io/security/#cloud-firewall Outbound ports¶ We recommend leaving all outbound ports open. Some providers like AWS EC2, Google Cloud, Digital Ocean forcefully block outbound port 25 for reducing email spam. The only way around this is to either request your server provider to unblock this port or better to setup an Email relay. It was a dumb issue hahaha omg I need some sleep.

Yes. It is.

I can't quite make out why it's crashing . @lukasgabriel if possible, can you write to support@cloudron.io and I can debug this further ?

Due diligence is as easy as checking out https://www.cloudron.io/pricing.html. Most services online make it that easy. The ones that don't, I just skip. By the way, by leaving Cloudron that must mean you've opted to use something else. I am curious what you've found, or had, that makes it worth not using Cloudron.

Thank you. That was my issue. I've followed the instructions on that thread and then truncated the syslog files which were around 50GB in size.

I am generally not in the group of AI = bad, however it likely just lacks lots of knowledge about the Cloudron internals, which make recommendations often not very useful in this area (yet). Overall I am still not sure based on this thread why DNS was involved here and given that you hit 3 different addons with apparently diverse issues, maybe something unrelated to them individually caused the trouble. We will add a few more helpers to the cloudron-support script for the future, to hopefully get down to such issues faster. If you haven't deleted the server yet, maybe we could take a closer look via SSH, since you already invested much time in debugging. If you want that, please enable remote ssh support and send a mail to support@cloudron.io with your Cloudron details.

We are reworking the notification UI for Cloudron 9 at the moment and the reboot required hint will be fixed accordingly there. It has caused quite a few misunderstandings in the past as it currently is

@Mamouti if you need (smallish) changes to the packages, feel free to submit MRs . All the packages are at https://git.cloudron.io/packages/

Thank you. I will try cloudron-support --troubleshoot next time.

@jpavlovski I confirm I had again three days ago

@joseph Here are some excerpts from the log around the time I noticed the problem ("XXXXX" were manually added): 025-03-31T14:41:08.552Z box:server ========================================== 2025-03-31T14:41:08.553Z box:server Cloudron 8.3.1 2025-03-31T14:41:08.553Z box:server ========================================== 2025-03-31T14:41:08.554Z box:platform initialize: start platform 2025-03-31T14:41:08.889Z box:tasks stopAllTasks: stopping all tasks 2025-03-31T14:41:08.889Z box:shell tasks /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all 2025-03-31T14:41:09.138Z box:shell All tasks stopped 2025-03-31T14:41:09.443Z box:locks releaseAll: all locks released 2025-03-31T14:41:09.486Z box:reverseproxy writeDashboardConfig: writing dashboard config for sebastienvigneau.xyz 2025-03-31T14:41:09.645Z box:shell reverseproxy: openssl x509 -in /home/yellowtent/platformdata/nginx/cert/my.sebastienvigneau.xyz.cert -noout -ocsp_uri 2025-03-31T14:41:09.757Z box:shell reverseproxy /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx 2025-03-31T14:41:12.464Z box:platform onActivated: starting post activation services 2025-03-31T14:41:12.464Z box:platform startInfra: checking infrastructure 2025-03-31T14:41:12.569Z box:platform startInfra: updating infrastructure from 49.8.0 to 49.8.0 2025-03-31T14:41:12.570Z box:platform markApps: changedAddons: ["mysql","postgresql","mongodb","redis"] 2025-03-31T14:41:12.736Z box:services startServices: existing infra. incremental service create ["start","startTurn","startMysql","startPostgresql","startMongodb","startRedis","startGraphite","start"] 2025-03-31T14:41:12.736Z box:mailserver startMail: starting 2025-03-31T14:41:12.739Z box:mailserver restart: restarting mail container with mailFqdn:my.sebastienvigneau.xyz mailDomain:sebastienvigneau.xyz 2025-03-31T14:41:12.882Z box:locks write: current locks: {"mail_restart":null} 2025-03-31T14:41:12.882Z box:locks acquire: mail_restart 2025-03-31T14:41:13.100Z box:mailserver configureMail: stopping and deleting previous mail container 2025-03-31T14:42:42.033Z box:mailserver createMailConfig: generating mail config with my.sebastienvigneau.xyz 2025-03-31T14:42:42.068Z box:mailserver configureMail: starting mail container 2025-03-31T14:42:42.068Z box:shell mailserver: /bin/bash -c docker run --restart=always -d --name=mail --net cloudron --net-alias mail --log-driver syslog --log-opt syslog-address=unix:///home/yellowtent/platformdata/logs/syslog.sock --log-opt syslog-format=rfc5424 --log-opt tag=mail -m 536870912 --memory-swap -1 --dns 172.18.0.1 --dns-search=. --ip 172.18.30.4 -e CLOUDRON_MAIL_TOKEN=XXXXX -e CLOUDRON_RELAY_TOKEN=XXXXX -e LOGLEVEL=info -v /home/yellowtent/boxdata/mail:/app/data -v /home/yellowtent/platformdata/addons/mail:/etc/mail:ro -p 587:2587 -p 993:9993 -p 4190:4190 -p 25:2587 -p 465:2465 -p 995:9995 --label isCloudronManaged=true --read-only -v /run -v /tmp registry.docker.com/cloudron/mail:3.15.0@sha256:c93b5a83fc4e775bda4e05010bd19e5a658936e7a09cf7e51281e3696fde4536 2025-03-31T14:43:33.399Z box:locks write: current locks: {} 2025-03-31T14:43:33.399Z box:locks release: mail_restart 2025-03-31T14:43:33.399Z box:docker deleteImage: removing registry.docker.com/cloudron/mail:3.14.9@sha256:c51a2ee20b2087e208084a9115cc6a525e3b3b227b52d8cfdac2d98a6409672e 2025-03-31T14:43:33.405Z box:services startTurn: stopping and deleting previous turn container 2025-03-31T14:44:04.243Z box:services startTurn: starting turn container 2025-03-31T14:44:04.243Z box:shell services: /bin/bash -c docker run --restart=always -d --name=turn --hostname turn --net host --log-driver syslog --log-opt syslog-address=unix:///home/yellowtent/platformdata/logs/syslog.sock --log-opt syslog-format=rfc5424 --log-opt tag=turn -m 268435456 --memory-swap -1 -e CLOUDRON_TURN_SECRET=XXXXX -e CLOUDRON_REALM=my.sebastienvigneau.xyz --label isCloudronManaged=true --read-only -v /tmp -v /run registry.docker.com/cloudron/turn:1.8.0@sha256:cdbe83c3c83b8f25de3a5814b121eb941b457dca7127d2e6ff446c7a0cfa1570 2025-03-31T14:44:15.397Z box:docker deleteImage: removing registry.docker.com/cloudron/turn:1.7.2@sha256:9ed8da613c1edc5cb8700657cf6e49f0f285b446222a8f459f80919945352f6d 2025-03-31T14:44:15.400Z box:services startMysql: stopping and deleting previous mysql container 2025-03-31T14:44:29.585Z box:services startMysql: starting mysql container 2025-03-31T14:44:29.585Z box:shell services: /bin/bash -c docker run --restart=always -d --name=mysql --hostname mysql --net cloudron --net-alias mysql --log-driver syslog --log-opt syslog-address=unix:///home/yellowtent/platformdata/logs/syslog.sock --log-opt syslog-format=rfc5424 --log-opt tag=mysql --ip 172.18.30.1 -e CLOUDRON_MYSQL_TOKEN=XXXXX -e CLOUDRON_MYSQL_ROOT_HOST=172.18.0.1 -e CLOUDRON_MYSQL_ROOT_PASSWORD=XXXXX -v /home/yellowtent/platformdata/mysql:/var/lib/mysql --label isCloudronManaged=true --cap-add SYS_NICE --read-only -v /tmp -v /run registry.docker.com/cloudron/mysql:3.5.0@sha256:969ea5b2f91861940ca6309c7676c52e479d2a864ba3aabd08a4266799707280 2025-03-31T14:44:36.436Z box:services Waiting for mysql 2025-03-31T14:44:36.442Z box:services Attempt 1 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.30.1:3000 2025-03-31T14:44:51.455Z box:services Attempt 2 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.30.1:3000 2025-03-31T14:45:06.732Z box:services Attempt 3 failed. Will retry: Error waiting for mysql. Status code: 200 message: connect ECONNREFUSED 127.0.0.1:3306 2025-03-31T14:45:22.063Z box:docker deleteImage: removing registry.docker.com/cloudron/mysql:3.4.3@sha256:8934c5ddcd69f24740d9a38f0de2937e47240238f3b8f5c482862eeccc5a21d2 2025-03-31T14:45:26.965Z box:services startPostgresql: postgresql will be upgraded 2025-03-31T14:45:26.965Z box:services exportDatabase: Exporting postgresql 2025-03-31T14:45:26.972Z box:services exportDatabase: Exporting addon postgresql of app 1bd225ff-a0e5-4f80-866f-99bd40115530 2025-03-31T14:45:26.973Z box:services Backing up postgresql 2025-03-31T14:45:26.976Z box:services exportDatabase: Error exporting postgresql of app 1bd225ff-a0e5-4f80-866f-99bd40115530. BoxError: Could not pipe http://172.18.30.2:3000/databases/db1bd225ffa0e54f80866f99bd40115530/backup?access_token=XXXXX to /home/yellowtent/appsdata/1bd225ff-a0e5-4f80-866f-99bd40115530/postgresqldump: connect ECONNREFUSED 172.18.30.2:3000 at ClientRequest.<anonymous> (/home/yellowtent/box/src/services.js:1350:47) at ClientRequest.emit (node:events:519:28) at emitErrorEvent (node:_http_client:101:11) at Socket.socketErrorListener (node:_http_client:504:5) at Socket.emit (node:events:519:28) at emitErrorNT (node:internal/streams/destroy:169:8) at emitErrorCloseNT (node:internal/streams/destroy:128:3) at process.processTicksAndRejections (node:internal/process/task_queues:82:21) { reason: 'Network Error', details: {} } 2025-03-31T14:45:26.976Z box:platform startInfra: Failed to start services. retry=false (attempt 0): Could not pipe http://172.18.30.2:3000/databases/db1bd225ffa0e54f80866f99bd40115530/backup?access_token=XXXXX to /home/yellowtent/appsdata/1bd225ff-a0e5-4f80-866f-99bd40115530/postgresqldump: connect ECONNREFUSED 172.18.30.2:3000 2025-03-31T14:45:26.976Z box:platform BoxError: Could not pipe http://172.18.30.2:3000/databases/db1bd225ffa0e54f80866f99bd40115530/backup?access_token=XXXXX to /home/yellowtent/appsdata/1bd225ff-a0e5-4f80-866f-99bd40115530/postgresqldump: connect ECONNREFUSED 172.18.30.2:3000 at ClientRequest.<anonymous> (/home/yellowtent/box/src/services.js:1350:47) at ClientRequest.emit (node:events:519:28) at emitErrorEvent (node:_http_client:101:11) at Socket.socketErrorListener (node:_http_client:504:5) at Socket.emit (node:events:519:28) at emitErrorNT (node:internal/streams/destroy:169:8) at emitErrorCloseNT (node:internal/streams/destroy:128:3) at process.processTicksAndRejections (node:internal/process/task_queues:82:21) 2025-03-31T18:15:19.191Z box:shell system: swapon --noheadings --raw --bytes --show=type,size,used,name 2025-03-31T18:15:19.505Z box:shell services: grep -q avx /proc/cpuinfo 2025-03-31T18:15:19.608Z box:shell services: systemctl is-active nginx 2025-03-31T18:15:19.610Z box:shell services: systemctl is-active unbound 2025-03-31T18:16:37.596Z box:shell system: swapon --noheadings --raw --bytes --show=type,size,used,name 2025-03-31T18:16:40.619Z box:shell system /usr/bin/sudo -S /home/yellowtent/box/src/scripts/reboot.sh 2025-03-31T18:16:40.968Z box:box Received SIGTERM. Shutting down. 2025-03-31T18:16:40.969Z box:platform uninitializing platform 2025-03-31T18:16:40.969Z box:shell system: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/reboot.sh errored BoxError: system exited with code null signal SIGTERM at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:137:19) at ChildProcess.emit (node:events:519:28) at ChildProcess.emit (node:domain:488:12) at ChildProcess._handle.onexit (node:internal/child_process:294:12) { reason: 'Shell Error', details: {}, code: null, signal: 'SIGTERM' } 2025-03-31T18:16:40.970Z box:system reboot: could not reboot. BoxError: system exited with code null signal SIGTERM at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:137:19) at ChildProcess.emit (node:events:519:28) at ChildProcess.emit (node:domain:488:12) at ChildProcess._handle.onexit (node:internal/child_process:294:12) { reason: 'Shell Error', details: {}, code: null, signal: 'SIGTERM' } 2025-03-31T18:16:40.977Z box:platform onDeactivated: stopping post activation services 2025-03-31T18:16:40.977Z box:tasks stopAllTasks: stopping all tasks 2025-03-31T18:16:40.978Z box:shell tasks /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all 2025-03-31T18:16:41.456Z box:shell All tasks stopped Anyway, I ended up running cloudron-support --recreate-docker, which made the apps functional again, and I am now restoring them from the backup one by one.

This support request is resolved. Should I delete this?

@thoresson said in SPF failure for IPv6 – but IPv6 is disabled on my server: @joseph No idea how, all I did was to take a break from this to cook dinner, but now it works. Probably just took a while for the changes you made to propagate

@joseph That's right! I thought that was the easiest way to increase the deliverability of emails sent from my Cloudron server. But apparently my understanding of DNS is lacking. I checked my VPS' ip address and it's not in any blacklists, so switching to the internal SMTP server.