Cloudron Forum

great, now you can mark this as a question/solved from the top post menu.

It's fixed a bit differently. The purpose of the "profile lock" feature is that admins have control over the username/mail/display name. Letting the user choose the username would circumvent this. This more so applies because when you have multiple admins, maybe one admin forgot to set the username (but they had decided by policy that they won't allow users to set usernames themselves).

Given that the profile lock is a 'dynamic' flag i.e can be set/unset at anytime, the fix we have put in place is:

username can now be set already created users with no username. When profile lock is set, username is required when creating new users. This way it's not possible for an admin to create users without a username. When profile lock is set, invite links of users with no username show a message to contact admin. (This message will only be seen if you had users created with no username and set the profile lock later. So, it's kinda rare)

@hendrikvl It's not a problem to have local network specific configuration in unbound. See https://docs.cloudron.io/networking/#private-dns .

As for the motivation, we use unbound because the mail server needs to do DNSBL queries. Most of the DNSBL servers like Zen SpamHaus will not respond if the queries originate from Google/Cloudflare DNS. This forces us to run our own DNS server.

The other motivation was also to log DNS lookups by apps to identify any malicious use but we never got around to this (this was initially designed for a setup where we expected all app packages to be done by 3rd party).

Finally, the unbound server should not be used much at all because most of the apps should not be querying anything external.

@girish The manual check method is good enough for me. If you do the release channel thing thats cool. But for those of us that a hungry, an extra few clicks isn't a bother.

@hendrikvl said in sender rewriting when using external SMTP:

And no, my mail relay does not accept IP whitelisting. It's not a proper mail relay service to be exact, but just a regular mail service with outgoing smtp for authenticated users.

Ah yes, someone was trying to do this with a gmail account as well sometime back (and more recently with a mailbox.org account). I think we have to implement this feature in Cloudron to make this use case work.

@girish Oops, I realized just now, that I didn't reply to your question yet. What I changed and maybe has to be protected from being accidentally overwritten is the 'datadirectory' option in /app/data/config/config.php. I changed that path from the default path to '/media/mymountpoint'.

I don't remember if I had Nextcloud in maintenance mode or put the app in recovery mode, while I changed that path and moved the files. But it was either of them. However, I had some duplicate storage paths in the database afterwards and I manually updated the oc_storages table as described here and did a files:scan afterwards. But that should not be related to what the code for updates overwrites, I guess.