@supervacuo Thanks for the report. I have fixed it for the next patch release. The max password length in the backend is 256 but the UI had a bug limiting it to 30.

You could use my yourls-repo (https://forum.cloudron.io/topic/1115/yourls-org-link-shortener-custom-app-request), add ldapauth to apache for your cloudron users and create links to your forms with yourls. If people click them, they have to auth via apache first and get forwarded after. This wouldn't be a link protection, but it would be a start 😉

@nebulon Okay. Thanks for clarification!

Sogo login issues

Some users have reported issues with logging into SOGo even when using the Cloudron email after the update. This is most likely because you are using an older version of SOGo. The old SOGo app was deprecated ~6 months ago as part of the 2.3 release and is not supported. Please move to the new SOGo immediately.

Install the latest version of the SOGo app (from the appstore) in another location/subdomain. You should see your email when logging in with email now.

If you use calendar/contacts in old SOGo, you can migrate it to the new SOGo using the guide at https://cloudron.io/blog/2018-12-05-carddav-caldav-migration.html

If everything is satisfactory, you can just uninstall the old SOGo.

Had this issue on support couple of times already: https://git.cloudron.io/cloudron/box/issues/610

This was resolved offline - most issues where related to unbound (the internal DNS server) being down. Fixed by System -> restart unbound.

This was a bug in our UI code. This is fixed in 3.5

@amg It seems there are multiple issues here:

Restore via CLI not working. Can you tell me more what the error is? Where are you seeing 'Already Setup'? Is this when installing Cloudron? (But the post starts with 'after update' to 3.4)

Please give us more information to help you out.

@CarbonBee Did I understand correctly that the DNS of cloudron A and Cloudron B are different above?

If so, the behavior is expected (not saying it is correct or even good). Currently, there is no easy way to easily 'migrate' domains - it is only easy to migrate a Cloudron from one server to another provided that all the DNS remains the same.

Can you explain your use case a bit more so we can try to come up with a solution together? I guess you are trying to test your backups? How can we make this work when Cloudron has multiple domains? Once you restore to another server, Cloudron will do the DNS setup of apps automatically and it will end up re-configuring the DNS of the apps to point to this new server.

@robw Sorry for the delayed response, we are just coming back from vacation and catching up on support tickets.

If I understand correctly, the Cloudron server has a different outbound IP than the one it detects. We have a custom endpoint (https://api.cloudron.io/api/v1/helper/public_ip) which helps us detect the IP of a server but I guess this detection goes wrong because of your setup.

To fix/workaround this: In the domain setup wizard, you can simply choose "no-op" as the DNS provider. With this provider, all DNS checks are disabled and as long as the domain somehow is able to resolve and reach your cloudron, it should all work. Another thing is that port 80 needs to be reachable as well for Let's Encrypt to work. If this is not possible, you can select 'Self Signed Certs' in the Advanced section of the domain UI.

Thank you, @gofaniyi and @girish!
Now everything works.

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.