I will mark this as solved since it was fixed with the update (3.4.3).

Great, thanks!

This is a UI bug in our current release (caused by an update to fontawesome..). You can fix it by doing this:

Open the browser console (firefox, chrome, safari) in the settings page. Run this command angular.element(document.getElementsByClassName('content')).scope().cloudronNameChange.show()

This will open a dialog that will let you set the name.

Some other elements are missing as well in the profile page. For that, run this:

angular.element(document.getElementsByClassName('content')).scope().displayNameChange.show() angular.element(document.getElementsByClassName('content')).scope().emailchange.show() angular.element(document.getElementsByClassName('content')).scope().passwordchange.show()

We will push an update next week.

Yep, thanks. it worked.

Can you check if the backup format is correct (i.e tgz or rsync) when you restore from the backups? The logs are in journalctl -u box -a.

I believe @scooke already got this sorted out.

The solution is to just start over with a fresh Ubuntu install and installing Cloudron. Another important thing to remember is to provide the correct version as part of the installation. It must be ./cloudron-setup --provider generic --version <version>. The version field is in the backup id.

I will mark this as solved, since it's unlikely we will start supporting another OS. Supporting two ubuntu versions is really hard as-is.

@thisiscowboy does this issue persist with the current mailtrain app package?

Just to conclude this thread. Mostly restarting the mail container will bring back the email server. As mentioned by @alexy this is done via docker restart mail

I will mark this thread as "solved", since it is quite old. If this issue is still there, please post a reply.

The wildcard dns would cover that just fine, so no need to take further action at the moment. Eventually during an update the box service will be anyways restarted.

Just for completeness, systemctl restart box requires root capabilities, so it has to run either as root user or through sudo

Is this still an issue? If not, was there a solution?

@tereensio is this issue resolved for you by now?

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