Cloudron Forum

Well, the thing is that I can obviously rename folders in my own account(s) in order to work around this, but when migrating accounts for other family members, colleagues or clients it's harder since I will be asking them to change their folder naming habits just because the mailsystem can't handle it.

To be honest I never ran into this with other mailsystems and I've used / tried a considerable amount of them in the meantime: Google (Gmail/workspace), Microsoft (hotmail/365), Zoho, Mailcow just to name a few and they all accept periods in folder names.
As a result we got used to use periods in our folder names.

I'm fine if the default stays as it is in order to not break anything for other people, but being able to change it when needed would be nice.
And yes, there are possible collisions with the internal folders (new, cur, tmp) when switching to FS, but this can be anticipated by setting the DIRNAME variable to something unique.

In regards with testing, I'm not sure this has a huge impact since the working of dovecot shouldn't change in any way when switching to FS.

@necrevistonnezr that's correct, but as you might understand this was just an example.
In reality it will be something like this@mydoman.com, that@mydomain.com and whatever@mydomain.com where wildcards are not a solution.

And we're up and running again!
Thanks again @girish , without your help I wouldn't be able to get it running again.

@girish since I recently had another issue as well, I was just thinking that maybe all this is related to the fact that I initially migrated from an older Piwik installation.
With that, I mean that after I installed the Cloudron app about 2 years ago, I imported existing data from that older Piwik installation. This might explain why I'm faced with those issues during upgrades while others aren't 🤔

@girish, fair enough.
I definitely understand your reasoning, but on the other side there is probably a good reason why the issue was added to the Matomo FAQ 🤔

@robi I think this says it all:

https://git.cloudron.io/cloudron/wordpress-managed-app/-/issues/32

@khadanja Indeed, OpenVPN uses a custom port and does not run over http(s)

@msbt no worries, I'm glad I for once can share my own solution to this great community 😉
Most of the time it's the other way araound 😆

Anyway, you have a point that Nextcloud's server-side encryption probably isn't worth it and therefore I'm also experimenting with Seafile, which has the possibility of client-side encrypted libraries. And in my (short) experience so far it is much much faster.
But unfortunately Seafile isn't currently available on Cloudron.

@andreasdueren said in Hide admin user(name)s for mail managers:

@girish personally I would enjoy the option to limit the E-Mail manager to the groups they are part of. For example some clients use so little resources like only a website with E-Mail that it doesn’t make sense to give them a dedicated server but instead put a few on the same.

Very good points as well, however as @girish says, as this would require to implement shared resources the idea is easier said than done. On the other hand, I personally can't see why it would not make sense to provide dedicated VPS at low cost for its own little resources needs to such client. In when you think about it, any client can grow and in such case the client is already set to scale without any more hassle. Cloudron is not too heavy for a simple basic use as it will adjust its own resources need only for the needs of the installed apps.

Now it would be nice if they could configure their own emails without being able to see let alone change the configuration of others.

Moreover, as explained previously if you install Cloudron for the client, a 10 bucks per month VPS would be more than perfect for such low needs, as superadmin you keep full control of the instance's management for the client and you give it admin privileges so it can fully manage its mail server. And with the upcoming multiple instances of Cloudron feature that should should become easier to manage from your side as well. 😊

@girish thanks

I will ask the teams of civicrm and MRBS to take care of this issue.

@girish Thanks!

@nebulon great to hear that it was already reported and fixed!

I didn't get any suggestions regarding similar topics, so I thought it wasn't reported yet.

@girish Thanks, now I managed to migrate the existing installation with the latest Matomo app package.
It was really straightforward!

@girish said in No backups because of NullPointerException:

@guyds said in No backups because of NullPointerException:

The first level is the per app level. Right now, apps are already backed up one by one, but they are not stored nor reported individually. And this is the missing feature in my opinion.

Ah no, they are listed in app -> backups. So, even if you do a full backup, each individual app backup will be listed in app -> backups.

Yes, they are listed at the app level, but there's no reporting at the app level because the backup succeeds or fails at the box level.

You can also use that backup to restore/clone the app.

Yes, but only if the backup succeeds for all apps.

So, again, I think the current issue is that everything is treated as a whole while it makes more sense in my opinion to treat each app individually and then in the end (optionally?) bundle the individual parts as a whole.

Yes, so they are treated individually, it's actually very close to what you want. The only issue is that when a full backup fails, those successful individual app backups that are part of a failed full backup will get removed/cleaned up every night.

Exactly, they are per app bot not treated like that in the end because success or failure is determined by the whole box.

I have made a task to fix the behavior, let's see.

Great, thanks!

@girish Thank you very much, this is greatly appreciated!

@humptydumpty done

@guyds said in Single domain, multiple cloudrons?:

I suppose each Cloudron needs a unique domain name because of the DNS records that are being created when installing a Cloudron: DKIM, SPF, DMARC?

Yes, and also because we need a unique location to access the dashboard.

what if the domain that's being used for a Cloudron already has e-mail related DNS records, for example when it's already configured for use with G Suite or Office 365? Will Cloudron modify those records, override them or just ignore them?

If you have an existing DMARC, it don't touch it. Otherwise, it will put the default strict DMARC policy. DKIM uses a unique selector domain, so it won't affect other DKIM entries. The SPF is modified with "a: my.<domain.com" into the existing SPF.