@ihtsham Yes, if you change the MX record of the client's domain to Cloudron's main domain i.e my.domain.com. When you have more clients, you can point all their MX domains to the same my.domain.com.

Well spotted @fbartels in fact 14.04 is not even supported by Cloudron at all, so it likely won't work anyways.

Getting a direct ssh connection into an app is not possible. All apps run in a separate container and are isolated from the main system. Depending on the app however, most apps have a read/write folder mounted from the host system into the container to store data. For example nextcloud is setup like this. The folder is located in /home/yellowtent/appsdata/<appid>/data/ and you could rsync data into this folder with the regular ssh connection to your server. You can easily see the appid if you open either the logs viewer of the app in question and take the appid from the browers url bar. Please note that this is merely a workaround so far and it depends on the app, if it correctly will pickup the data there.

@scottharvey do you still see the issue or have more information on this, like @girish asked? If not, we should probably close this thread.

Is there any more information on this? For me all my clients I use, have the option to display folders as threaded or not, they also have then different sorting means depending on threaded or not.

@enesaydogan we have changed our pricing and the user limitation is now lifted.

After contacting Digital Ocean support and answering a few questions about my email usage they unblocked port 587 so I can send email now. Thanks for the help.

@girish thanks for the info and extra-feature, that's good to know and might come in handy! I'll also tell people not to use that long filenames to avoid such errors.

Hey, thanks guys!

You might want to consider putting a message on the invoices page or somewhere else about this, to be more explicit. Anyway, thanks for your help (and for cloudron!), I'm glad to know it went through alright.

Cheers!

Oh indeed, currently Cloudron only supports Ubuntu 16.04 as being an LTS release for now. Sorry that it wasn't clear upfront.

Just tried this and it works for me.

Note that I too see the following message in my logs:

Aug 02 17:29:34 my.smartserver.space dockerd[20759]: time="2018-08-02T17:29:34Z" level=info msg="loading plugin "io.containerd.snapshotter.v1.btrfs"..." module=containerd type=io.containerd.snapshotter.v1 Aug 02 17:29:34 my.smartserver.space dockerd[20759]: time="2018-08-02T17:29:34Z" level=warning msg="failed to load plugin io.containerd.snapshotter.v1.btrfs" error="path /mnt/volume_sfo2_01/docker/containerd/daemon/io.containerd.snapshotter.v1.btrfs must be a btrfs filesystem to be used with the btrfs snapshotter" module=containerd Aug 02 17:29:34 my.smartserver.space dockerd[20759]: time="2018-08-02T17:29:34Z" level=warning msg="could not use snapshotter btrfs in metadata plugin" error="path /mnt/volume_sfo2_01/docker/containerd/daemon/io.containerd.snapshotter.v1.btrfs must be a btrfs filesystem to be used with the btrfs snapshotter" module="containerd/io.containerd.metadata.v1.bolt"

But the above error is harmless. It is just saying that for btrfs plugin we need btrfs volume. This can be ignored since Cloudron does not use btrfs plugin.

As others said, usually the cron job is part of the app itself. If for some reason you want to run some cron task outside the scope of the app, then you can use a script like below and put it in the crontab of your server.

#!/bin/bash # this is the app's domain name app="test.smartserver.space" # detect the container id of the app container_id=$(docker ps -q -f label=fqdn=$app -f label=isSubcontainer=false) echo "App container id is : $container_id" # we can now run arbitrary commands in the container. below we run a command as the www-data user. docker exec $container_id sudo -u www-data ls -l

I guess we can add this feature as part of https://git.cloudron.io/cloudron/box/issues/465

Aha, I'd glossed over the bit in the instructions that said to put the IP in the address bar -- I'd punched in the actual domain name and gotten a 404; that combined with the fact that the installer process saying it was waiting for cloudron to start had me thinking something had gone wrong. It's working now. Derp. Thanks for your help.

Okay. I've sent the log in mail to support, and provided additional background and specifics.

Oh I pasted the wrong link apparently, fixed it now.

I forgot to post a follow up on this thread. I'd like to thank @girish for solving my problem. He responded quickly and arranged to ssh into my server to diagnose. He's been very patient and professional and I really appreciate it.

Basically the problem is due to MySQL addons not properly starting/building, so all apps using MySQL error out and cannot start or install. Hope the problem has been resolved in the final 2.4 releases 🙂

For the record, I hit that issue too. /boot got full. However, I could not fix it with the solution at https://forum.cloudron.io/topic/1310/disk-filled-up-with-kernel-update-artifacts/2 . I had to follow https://askubuntu.com/a/430944 (slightly adapted)

@nebulon said in Disk filled up with kernel update artifacts:

rm -rf /var/tmp/mkinitramfs*

I had to instead do:

cd /var/tmp find . -type f -delete -print

This was running for like 5 hours! (and still running)

In another server instance hit by https://forum.cloudron.io/topic/1382/error-for-multiple-apps/12, recreating docker containers did not help. I even disabled apparmor altogether using sudo systemctl stop apparmor and sudo systemctl disable apparmor. We tried server restart as well and that didn't help either.

After disabling apparmor, I saw that mysqld would just quit without showing any error message or log output 😞 As a final thing, I just ended up moving platformdata/mysql to mysql-old and recreated containers again. That made mysql come up and then we restored all the apps.

Still a bit crazy/worrying that we hit this bug atleast twice now and there is no clear resolution.

For others reading this, currently the process of giving build service access is not automated. If you need access, please send us an email to support@cloudron.io.

@rtyu1120 for hackmd there is already some progress https://forum.cloudron.io/topic/1222/hackmd-fast-and-flexible-real-time-collaborative-markdown/10

@girish I also realized that the mysqldump for the TT-RSS app is huge (679 MB in my case). Could you implement some compession in the database dumps (and use PostgreSQL as recommended by the author)?

@uiharu Ah, thanks!

Ah my bad, for whatever reason I deleted the DNS entry and didn't check what was up, all my fault :s

@girish working. thanks!

Thanks again! Everything is up and running now!

@scooke Right, so the newapp.app@domain.com is the default allocated mailbox. If you want to make the app use a different email address, you have to do this https://cloudron.io/documentation/email/#changing-the-from-address-of-an-app . It's geeky, we are looking into fixing this in the next release since this is often requested.