As @jdaviescoates said, we force small case for compatibility. I understand that in your specific context that being case sensitive might work though. LDAP itself has a bunch of case sensitivity madness. See https://stackoverflow.com/questions/29897684/is-ldap-dn-case-insensitive and https://www.ibm.com/docs/en/oala/1.3.5?topic=SSPFMY_1.3.5/com.ibm.scala.doc/install/iwa_pinst_ldap_cnf_cse_sen_t.html . I remember we tried to make this case preserving but this causes lots of subtle very hard to debug failures. There's a lot of things in play here File systems, databases, frameworks, languages... each has their own level of case sensitivity support when it comes to usernames.

@qilin said in New to Cloudron. Having different issues: The strange part is that there are no bans which is worrisome to me. So, this doesn't work most because fail2ban itself works by scanning log files and as you said, there is nothing in the auth.log. Generally, this is outside Cloudron configuration (as in, Cloudron does not configure or update all this on the server). My understanding is sshd logs always to syslog. You can check the Facility with which it logs in /etc/ssh/sshd_config. I think from there it goes to /etc/rsyslog.d/* config files to log based on the facility. Not 100% sure, maybe others can chime in.

@girish I did something slightly different (but maybe not SO uncommon). I created the server and put the clients domain into my own (developer) cloudflare account. After everything worked I created the domain in the client's cloudflare account and changed the NS entries (basically this: https://developers.cloudflare.com/fundamentals/get-started/basic-tasks/manage-domains/move-domain/). the situation was now, that the API key was still valid but changed the wrong domain entries at cloudflare. so, I imagine cloudron creates the NS entry, checks if this works (which it doesn't) -> brain freeze. Something like this?

@humptydumpty I am not sure about windows since I use Linux but I tried to search a little for an answer. It seems to be related to HTML5 canvasing. Maybe you can try this on FF: Mozilla Support: Firefox protection against fingerprinting

@humptydumpty done

@fbartels ok, this makes sense, thanks!

@prologic said in First-time install, Login, Password invalid: The Password Reset also fails (presumably because Email is not setup yet on a first-time install?) Email also only starts working after you have signed up in the App store UI.

@Robin Yeah, I think what you did is the correct approach. Given that we don't have a "I know what I am doing button..."

@nebulon Thanks!

This is taken care of now via support ticket.

@girish Mailgun. It hasn't happened again (so far). BTW, the notification error listed only two out of ten domains (all using Mailgun).

@girish perfect! Thank you so much! I really highly appreciate the effort! Thanks! I see it now!

@nick We have deployed a (possible) fix now, can you please try again?

@perler We replied from support@ now, can you please check? For future reference, the approach is: Login to cloudron.io with your old account. Delete the cloudron instance there. This will disassociate your existing Cloudron from cloudron.io Then, go to your Cloudron dashboard. If you refresh the page and go to Appstore view, it will ask you to relogin. Just relogin with your new cloudron.io account. If your new account has a license, it will automatically get reassociated. If this doesn't, please send us a note on support@ and we can fix it up.

@girish thanks for the support. Now they are available in the app section .

@kk_cloudron that is correct, Cloudron requires IPv4 and does not work on IPv6 only servers (yet).

Not sure how related this is, but my SSHFS mounts are also not working, recently. Just saying.

@subven I not joe lol I just search this forums and found this and same as my server showing but it worked my side now:) Thank you and I do not know about his side yet