Yes, I've been doing this for years, you just have to make /app/data friendly enough for apps to find what they need. This generally involves setting a few env variables: HOME PATH LD_LIBRARY_PATH (less common) other app specific ENVs All of these changes do not affect the running app since it's already running with its own ENVs. So these are great for additional services. Nice work @djxx

There are now many post about mail and IPv6 included PTR. The forum search is a powerful tool You need to set the PTR Record for your IPv6 in your hoster.

@joseph I wanted to also ask a question outside this cloudron scope and see if you can point me to the right direction. I am looking for how to write a script that has the capcity to run any file in any type of OS remotely. Meaning I can just download and the file runs on the script fully/silently without forcing any permissions on my user interface. For example if i want to send updates on a particlar software, i just want it to be downloaded and run without user being able to prompt and allow permissions

So I have played about for days, I did this because when trying EmClient, it said there was an SSL issue, and it was not the only place I saw an SSL error, and when clicking reissue, I saw there were lots of issues with trying to generate a SSL for imap.domain.name I changed the mail server URL from imap.domain.name to my.domain.name and then checked DNS. I noticed the DNS had not been updated, did it manually. I checked the logs as the process was being done, it stated that the DNS record had been updated, but it had not. Since changing my mail server address to the same URL as my cloudron server, the connection seems to be more stable, with faster responses and no SSL errors. Outlook it still not working and seems to find the old URL where as all other apps are seeing the new URL and still loading the imap.domain.name, we have given up on this issue. What is the point in being able to change the domain name and subdomain of the mail server when it don't seem to be liked by mail clients.

Seems like a few issues intermixed here. For a start userland proxy in docker should be false. This set however in /etc/systemd/system/docker.service.d/cloudron.conf by the cloudron startup script. On port 172.18.0.1:3003 the Cloudron docker proxy addon would listen, so this also hints at docker having an issue with the network bridge it supposed to have created. Otherwise most likely if you had a disk being 100% full situation, all bets are off, unfortunately. This is not so much related to Cloudron code but other linux services we use like mysql and docker

@nebulon I’m wondering… since Cloudron depends entirely on Docker networking to function… is there maybe room to improve the IP blocklist checking so that it ignores any entries of the current Docker networking ranges such as 172.18.xxx.xxx addresses? It feels to me like there would never be a use-case to block those, and while we certainly need to use reliable IP lists (lesson learned, haha), I also wonder if this feature should be improved in the future to ignore any private IPs or at least any Docker IPs.

Thanks to everyone for the responses. I fully understand the backups now and have reported to my board that it's indeed production ready for our organization.

That worked @girish cloudron-support --troubleshoot found a certificate which does not exist and so removed a conf file nginx started promptly After which the Cloudron apps could be restarted just fine Thank you once again for your help

@BrutalBirdie Merci

@basiliolp the forum search is a powerfull tool Welcome to the Cloudron Forum https://forum.cloudron.io/topic/13654/could-not-connect-to-your-mcp-server/

Could you please convert that thread into a request to remove 'Cloudron' from the mail templates as well as from translation files, please?

@nebulon I appreciate your advice. The backup server is not on the same location as the cloudron server. It isn't even on the same country (like I do with all my backups). Maybe I wasn't clear: the server has an OS disk (nvme) and a HDD for backups. The mount I showed is the HDD disk mount. It was just to check if any filesystem mount options were needed to improve performance. Thank you all.

We finally got down to this issue. Problem was that particular instance had a lot of backups in the db and we only took the first 1k backups into account for purging. Fix is coming with next release. If you hit this issue, send us a mail to support@cloudron.io so we can apply a temporary fix.

It was not fail2ban - it was IPv6 connection which is failing, as IPv6 disabled (to ensure mail works well). Hetzner's supported provided a very quick and efficient verification / troubleshooting step: ssh -vvv -p 23 user@server - hope that will be of use for anyone else in the future.

I will close this for now since it's not meant to be run directly . We can continue in the other thread or we can open a new thread .

@necrevistonnezr That is because https://git.cloudron.io/ is currently throwing err 500. [image: giphy.gif] Has been resolved, is now all good again.

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.