Cloudron Forum

Did you set-up a PTR record for your IPv6 and checked all of the IPv6 threads on the forum (if you haven't you'll find several using the search function)?

Hi, did you check this, this and this? I got the similar errors when trying to run the indexing but after a few retry it works.

I tried to index email mailbox separately (by running the command inside the rebuild-index.sh for each mailbox separately) and identified which one caused the problem, then I had to open/read the problematic folders with a mail client, and then the index worked.

Given this feels like another duplicate, @staff, there might be something up / to improve with how the indexing is handled.

@joseph said in Email search not working properly:

The tika error seems to be because tika was down .

What's tika?

Btw I did all mailboxes manually, I had to retry a couple but they all ended up indexing without errors in the end.

@joseph said in Email search not working properly:

I think a UI button to rebuild index will help a lot.

Yes to that! Though whatever the solution chosen it's gotta be robust against the process failing / encountering errors. So either a button per mailbox, or if global, then it needs to make sure it carries on even if if there are errors on one mailbox.

Ok so I followed the steps indicated in the doc and there was a quirk. On a mailbox I got some errors:
Error: Mailbox INBOX/somefolder: Precache for UID=47 failed: Internal error occurred. Refer to server log for more information. [2025-03-30 07:54:41] doveadm(mail@domain.coop): Error: fts_tika: PUT http://127.0.0.1:9998/tika/ failed: connect(127.0.0.1:9998) failed: Connection refused

And then this stopped the indexing process altogether. So I had to manually run the command in the rebuil-index.sh script separately for all my mailboxes, avoiding the one that caused troubles, and on any mailbox where rebuilding the index worked, then search works again

Here is the detailed log related to the error above

2025-03-30 07:54:41.788 INFO  (searcherExecutor-16-thread-18-processing-dovecot localhost-1846) [c: s: r: x:dovecot t:localhost-1846] o.a.s.c.QuerySenderListener QuerySenderListener done.
2025-03-30 07:54:41.789 INFO  (searcherExecutor-16-thread-18-processing-dovecot localhost-1846) [c: s: r: x:dovecot t:localhost-1846] o.a.s.c.SolrCore Registered new searcher autowarm time: 3 ms
2025-03-30 07:54:41.802 INFO  (qtp2067925017-24-localhost-1846) [c: s: r: x:dovecot t:localhost-1846] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{commit=} 0 129
2025-03-30 07:54:41.818 INFO  (qtp2067925017-25-localhost-1847) [c: s: r: x:dovecot t:localhost-1847] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{add=[1/7824dd26093d43618202000011c04ec4/mail@domain.coop (1828004856394153984)]} 0 9
2025-03-30 07:54:41.831 INFO  (searcherExecutor-16-thread-18-processing-dovecot localhost-1848) [c: s: r: x:dovecot t:localhost-1848] o.a.s.c.QuerySenderListener QuerySenderListener done.
2025-03-30 07:54:41.832 INFO  (searcherExecutor-16-thread-18-processing-dovecot localhost-1848) [c: s: r: x:dovecot t:localhost-1848] o.a.s.c.SolrCore Registered new searcher autowarm time: 4 ms
2025-03-30 07:54:41.833 INFO  (qtp2067925017-24-localhost-1848) [c: s: r: x:dovecot t:localhost-1848] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{commit=} 0 13
2025-03-30 07:54:41.922 INFO  (qtp2067925017-25-localhost-1849) [c: s: r: x:dovecot t:localhost-1849] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{add=[1/288a8522203d43618202000011c04ec4/mail@domain.coop (1828004856499011584)]} 0 13
2025-03-30 07:54:41.934 INFO  (searcherExecutor-16-thread-18-processing-dovecot localhost-1850) [c: s: r: x:dovecot t:localhost-1850] o.a.s.c.QuerySenderListener QuerySenderListener done.
2025-03-30 07:54:41.936 INFO  (searcherExecutor-16-thread-18-processing-dovecot localhost-1850) [c: s: r: x:dovecot t:localhost-1850] o.a.s.c.SolrCore Registered new searcher autowarm time: 3 ms
2025-03-30 07:54:41.936 INFO  (qtp2067925017-24-localhost-1850) [c: s: r: x:dovecot t:localhost-1850] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{commit=} 0 12

These seem to relate to some kind of time out issues. I also got some of these errors on another mailbox which I have set-up on a desktop email client, and by opening the problematic folders with the mail client and then rerunning the rebuilding of the index then it worked.

So wonder if something could be improve to make building/rebuilding the index more robust?

@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):

but 1) you have to pay 6 months in advance (whereas with Hetzner you can just pay for an hour if you cancel), 2) their default Ubuntu is stripped down and so installing Cloudron doesn't work until you mess around installing full Ubuntu first 3) their UI/ UX is just no way near as good as Hetzner's, etc.

Just to say, I used to be with Hetzner and I am now with Netcup and regarding: 1) you do NOT have to pay 6 months in advance (it's just cheaper if you do); 2) I had no such issue with their ubuntu version. I've installed Cloudron from blank ubuntu from Netcup and I've been running several Cloudron instances with no problems. Totally agree with 3), Hetzner UI is SO much better...but then their prices are also significantly higher so I'd rather get better hardware and a lesser friendly UI.

However on my servers, and despite following all the right steps, I kept having issue with IPv6. PTR records and DNS all check OK on Cloudron, MX checks etc, but I keep getting random email bounce from Gmail. The only final solution was to disable IPv6 completely. Perhaps Hetzner is better in that respect.

@ekevu123 said in Planka - A Trello-like Kanban board React/Redux:

Planka looks nice, sure, but it doesn't seem to offer a proper mobile layout or an app.

Actually I think it does:
https://github.com/plankanban/planka?tab=readme-ov-file#mobile-app
https://github.com/LouisHDev/planka_app

I know we already have wekan, kanboard, etc but this one has a really lovely and clean interface. Less feature rich but great for easy use and actively developed. Don't know how hard it might be to package but it would be cool to have.

@joseph said in Email search not working properly:

@avatar1024 try https://docs.cloudron.io/email/#solr-index-corruption . The index is probably corrupt .

Thanks! I'll properly test tonight in downtime hours....but how the f**k have I missed that in the doc

Sorry for the bother if the solution is that simple and thanks for everyone's help.

I've tried again the above steps but now I used doveadm -c /run/dovecot.conf index -u mail@domain.com '*' as the index command and I'm not getting any errors...but also not getting any search results (all searches in roundcube return Search found no matches). I tried on a very small mailbox where indexing shouldn't take anytime at all. Don't know if that's what's supposed to happen but that index command return to the prompt instantaneously, which seems weird.

Also for info, I gave the mail service 6GB ram so shouldn't be a resource issue.

Thank you, I followed those steps but I'm getting a lot of: Error: fts_solr: Indexing failed: 404 Not Found

I've looked at that thread in more details as it seems like @d19dotca was facing similar issues when following those steps, yet the link that @girish provided doesn't exist anymore so I couldn't really see how to solve it. I tried to add the -c argument to the index command but that on its own didn't work and I was still getting those errors.

I have disabled full text search for now and at least basic searches are working normally until this is resolved.

Hello,

I've noticed that email search has been weird over the past few days (might have been longer, not sure when it started), where the search in roundcube and snappymail returned result from email only from the last week but not for older emails.

I tried to deactivated and reactive full text search in Cloudron but since then I get no search result at all ...

I read the Cloudron doc but couldn't see anything obvious.

Running Cloudron 8.3.1.

Ok this regex to whitelist all groups except "admin" seems to work well : ^(?!admin$).+$

@joseph Thanks, that worked!

So far I haven't been able to allow all groups but exclude "admin", but when I only allow only a specific group then the admin group is not provisioned and works as expected.

@joseph said in Nextcloud OIDC integration:

can nextcloud admin group have an arbitrary name or should it be admin(s) ?

In NC the group name for Admins is "admin". You can't change that and you can't create another group with admin rights. And in Cloudron one cannot create a group called "admin" (as you say the name is reserved). It feels like either:

• Cloudron admins and Super admins should be mapped with the NC admin group
• OIDC group syncing should exclude syncing the NC admin group

Anyone know if there is there a way to customize the OIDC login button for Listmonk? Currently for me it says "Login with .org.uk" instead of my domain or organisation name which is rather unhelpful. Thanks!

@jdaviescoates Yeah so it also works for me if I don't activate group mapping / syncing but I was asking if there is a solution to add admins users with that enabled.

On one instance we used LDAP groups syncing and so switching to OIDC we need to also sync groups...but then we also needs admins

Anyone got a clue?

PS: I've tried with my user who is a cloudron superadmin and with another user who is a Cloudron admin. None of them appear in the NC admin group or can be added to it.

@jdaviescoates Thanks! Have you activated group mapping / syncing though? For me it's not working. I cannot add myself to the admin group (and I have definitely logged in - in fact that's how I know I'm not an admin ). I can login with the "admin" user via the Nextcloud form but cannot add anyone else to the admin group, including myself.

@girish said in Nextcloud OIDC integration:

OIDC Group Sync has to be configured by the package installer just like LDAP Group Sync.

Hi @girish

So is there a solution to add users in the Nextcloud admin group with OIDC group mapping activated?

Group mapping works well but when I add users to the admin group from the Nextcloud user interface it doesn't work (as noted by @jdaviescoates earlier in this thread).

@whitespace said in Nextcloud OIDC integration:

Nextcloud accounts that do not exist in Cloudron user directory should be able to log in via Nextcloud login form.

This seems to be working as expected. Some users in one of my Nextcloud instance are not Cloudron users and after the update enabling OIDC they haven't been logged out and their credentials seem to be working as usual.

@girish said in Nextcloud OIDC integration:

A leaked raw password of the platform has very big implications (compromises all apps)

Very much agreed with that and overall I take your point about wanted to prioritise more secured routes. This approach does increase security but I would say only marginally, and with that reasoning we could make cloudron and various apps even more secured but at the further expense of convenience, which I don't think anymore would be up for.

Security is about a range of practices which have somewhat a hierarchy. Things like encrypting your device hard drive being probably the overarching security measure when it comes to password protection, along with using apps that transmit login details securely between device and server (though storing securely is less of a problem if device is encrypted) and using an proper password token / manager. Otherwise if someone get physical access to your device, it is likely they will get access to the platform password by some other means, for example from the web browser where, unless told otherwise, casual users will keep their platform password stored for convenience.

Sure no one is saying we should make the task easy for anyone attempting an attack like keeping all your passwords in a plain text file on your desktop, but wanting to protect the platform password by making usability much worst, where in fact the main security culprit is elsewhere (in people devices encryption and password practices) I'm not sure makes much sense. That's just my opinion, I'm happy to be told wrong and it is also not my place to tell you about security choices :).