@tbroady do you have any update on this? Can we mark this as "solved"?

Since your provider does not support multiple PTR records per ip, I think this is only solvable in your case by using a email relay.

@fbartels Yes, the format of cloudron.json had changed between the CLI version. We didn't write the migration code since we thought it wasn't important.

@nebulon said in Large file not syncing in Nextcloud / cannot set max file size for syncing:

So you are saying, one of those now disabled plugins/apps were causing the issue then?

It seems so... I disabled

https://apps.nextcloud.com/apps/bruteforcesettings https://apps.nextcloud.com/apps/files_antivirus https://apps.nextcloud.com/apps/ransomware_detection https://apps.nextcloud.com/apps/ransomware_protection

Now everything works as intended.
The error when setting the max upload file size still exists though.

Sorry for that, the renewed certs are now deployed.

Thanks @girish, that did the trick and lead straight into Backup Improvements: Restic as Backend.

There is an entry in the issue tracker for powerdns already at https://git.cloudron.io/cloudron/box/issues/117

Regarding the Linux distribution, we currently only support Ubuntu in versions 16.04 and 18.04 and due to testing effort, we don't currently plan on adding further distributions.

@gofaniyi SOGo is a "frontend" to email. The emails itself are stored in the backend which is part of Cloudron. Practically, what this means is that if you install some other email frontend like rainloop or roundcube, you will be able to see the same emails.

To answer your question, all the data will be in /home/yellowtent/boxdata/mail/vmail. You will find directories organized by domain.com/username. They are all in maildir format.

Actually, the next time, if you run any linux distribution on your pc, then I would recommend to install imapsync there and do the one-time syncing, this avoids having to install additional packages alongside of Cloudron on that server.

Cloudron will "take over" the server and also manages the packages and services, which are installed. Generally it is not supported to install anything on the side. In this case Cloudron depends on mysql-server-5.7 which will probably uninstall mariadb through apt.

@nebulon Thank you very much. Yes, the server was done for a while but now back online :).

Hi,

the application's data path can be found at /home/yellowtent/appsdata/<appId>/data/ and that is the only writeable path for apps (besides /tmp and /run of course). This is done for security as well as predictability for updates. Usually if you push data there through external means like SSH, you might have to reconfigure the app through the dashboard, in case the file permissions are not correct. Generally it is preferred that data changes are done via the app itself, which I guess is not quite applicable for your use-case though.

For duplicator, from what I understand this migration script is mostly just creating a tarball/zipfile of the whole previous installation and then extracts it into a folder, which is served up by some LAMP environment. This is incompatible with the Cloudron WordPress package, for reasons mentioned above (mostly the read-only fashion) For this you probably have to fallback to the LAMP app itself. There it should work.

Thank you @girish for the refund!
Much, much appreciated!

Amazing. Thank you!

From the next version, we don't require port 80 to be open since we support acme2 DNS based validation.

@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.

@nebulon
I tried again, and the widget worked!
I saw only a simple text link because it was wrong. The correct address starts with https://.
(The example code start with http:// but Mailtrain on Cloudron uses https://)

After getting this worked, I'm started to want to customize the widget.
(e.x. I want to use "Thank you for subscribing!" instead of the default message says "It looks like you are already subscribed to this list.")
There's a file called widget-subscribe.hbs where we can customize the appearance of the widget.
However, it is not accessible on Cloudron.

Is(Will be) there any way to customize the widget?

@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